まず、リソース リークを提案した他の投稿者に同意します。あなたは本当に最初にそれを除外したい.
願わくば、現在使用しているヒープ マネージャーに、ヒープ内で使用可能な実際の合計空き領域 (すべての空きブロックにわたって) と、分割されているブロックの合計数をダンプする方法があります。空きブロックの平均サイズが、ヒープ内の合計空き領域と比較して比較的小さい場合は、断片化の問題があります。または、最大の空きブロックのサイズをダンプして、それを合計の空き領域と比較すると、同じ結果が得られます。断片化が発生している場合、最大の空きブロックは、すべてのブロックで使用可能な空き領域の合計に比べて小さくなります。
上記について明確にするために、すべての場合において、ヒープ内の割り当てられたブロックではなく、ヒープ内の空きブロックについて話しています。いずれにせよ、上記の条件が満たされない場合は、何らかのリーク状況が発生しています。
したがって、リークを除外したら、より優れたアロケーターの使用を検討できます。質問で提案されているDoug Lea の mallocは、一般的な用途のアプリケーションに非常に優れたアロケーターであり、ほとんどの場合非常に堅牢です。別の言い方をすれば、ほとんどのアプリケーションで非常にうまく機能することが実証されています。ただし、すべてのアプリケーションに最適なアルゴリズムはありません。管理アルゴリズムのアプローチは、その設計に対する適切な病理学的条件によって破られる可能性があります。
断片化の問題が発生するのはなぜですか? - 断片化の問題の原因は、アプリケーションの動作によって引き起こされ、同じメモリ アリーナ内で大きく異なる割り当ての有効期間に関係しています。つまり、一部のオブジェクトは定期的に割り当てられて解放されますが、他のタイプのオブジェクトはすべて同じヒープ内で長期間存続します... 寿命の長いオブジェクトは、アリーナのより広い領域に穴を開け、それによって攻撃を防ぐものと考えてください。解放された隣接ブロックの合体。
この種の問題に対処するためにできる最善の方法は、ヒープを論理的にライフタイムが類似したサブアリーナに分割することです。実際には、一時的なヒープと永続的なヒープ、または似たようなライフタイムのものをグループ化するヒープが必要です。
問題を解決する別の方法として、割り当てサイズをより類似または同一にする方法を提案している人もいますが、内部フラグメンテーションと呼ばれる別のタイプのフラグメンテーションが作成されるため、これはあまり理想的ではありません。必要以上のメモリをブロックに割り当てることによって。
さらに、Doug Lea のような優れたヒープ アロケーターでは、ブロック サイズをより似たものにする必要はありません。これは、アロケーターが既に 2 のべき乗サイズのバケット スキームを実行しているため、malloc( ) - 実際には、彼のヒープ マネージャーは、アプリケーションが調整できるよりもはるかに堅牢に自動的にそれを行います。