手動メモリ管理

コンピュータサイエンスにおいて、手動メモリ管理とは、プログラマが手動の命令を使用して、使用されていないオブジェクト、つまりガベージを識別して割り当てを解除することを指します。1990 年代半ばまで、業界で使用されていたプログラミング言語の大部分は手動メモリ管理をサポートしていましたが、ガベージコレクションは1959 年にLispで導入されて以来存在していました。しかし今日では、ガベージコレクションを備えたJavaなどの言語の人気が高まっており、 Objective-CやSwift などの言語は自動参照カウントを通じて同様の機能を提供しています。現在でも広く使用されている主な手動管理言語はCとC++です。Cの動的メモリ割り当てを参照してください。

多くのプログラミング言語では、フリー ストアから新しいオブジェクトを割り当てるmallocタイミングを決定するために手動の手法が使用されています。C では関数が使用され、C++ と Java ではnew演算子が使用され、他の多くの言語 (Python など) ではすべてのオブジェクトがフリー ストアから割り当てられます。オブジェクトをいつ作成するか (オブジェクト作成) の決定は、通常、簡単で問題はありませんが、オブジェクト プールなどの手法を使用すると、オブジェクトがすぐに使用される前に作成されることがあります。実際の課題はオブジェクトの破棄、つまり、オブジェクトが不要になった (つまり、ガベージになった) タイミングを決定し、その基礎となるストレージを再利用のためにフリー ストアに戻すように手配することです。手動のメモリ割り当てでは、これもプログラマによって手動で指定されます。Cfree()の などの関数、またはC++ の 演算子を介して、これは自動変数deleteに保持されるオブジェクト(特に、C および C++ でスコープの終了時に破棄される関数の (非静的)ローカル変数) の自動破棄とは対照的です。

例えば

• malloc/free
• 記憶のアリーナ
• スクラッチバッファ

手動メモリ管理は、誤って使用されると、プログラムにいくつかの主要なバグ、特にメモリ安全性の侵害やメモリ リークを引き起こすことが知られています。これらは、セキュリティ バグの大きな原因です。

• 使用されていないオブジェクトが空きメモリに解放されない場合、これはメモリ リークと呼ばれます。存続期間中に限られた量のメモリを「リーク」するプログラムや、終了時にリソースの割り当て解除をオペレーティング システムに依存する実行時間の短いプログラムなど、メモリ リークが許容される場合もあります。ただし、多くの場合、メモリ リークは実行時間の長いプログラムで発生し、そのような場合には無制限の量のメモリがリークされます。これが発生すると、使用可能な空きメモリのサイズは時間の経過とともに減少し続け、最終的に使い果たされると、プログラムはクラッシュします。
• 動的メモリ管理システムの壊滅的な障害は、オブジェクトのバッキング メモリが複数回削除された場合、オブジェクトが明示的に複数回破棄された場合、フリー ストアに割り当てられていないオブジェクトを操作するためにポインタを使用しているときに、プログラマがそのポインタのターゲット オブジェクトのバッキング メモリを解放しようとした場合、または、未知の外部タスク、スレッド、またはプロセスによって管理されている別の任意のメモリ領域へのポインタを介してオブジェクトを操作しているときに、プログラマがそのオブジェクトの状態を破壊した場合 (境界外への書き込みやメモリ管理データの破壊など) に発生する可能性があります。このようなアクションの結果、ヒープの破損、複数回削除されたオブジェクトと同じメモリ位置を占める別の(新しく作成された) オブジェクトの早期の破壊、セグメンテーション違反(メモリ保護違反) によるプログラムのクラッシュ、その他の未定義の動作が発生する可能性があります。
• 削除されたオブジェクトへのポインターは、削除後に使用されるとワイルド ポインターになります。このようなポインターを使用しようとすると、診断が困難なバグが発生する可能性があります。

ガベージ コレクションのみを使用する言語は、最後の 2 つのクラスの欠陥を回避できることが知られています。メモリ リークは依然として発生する可能性があります (また、世代別または保守的なガベージ コレクションでは、制限付きリークが頻繁に発生します) が、通常、手動システムでのメモリ リークほど深刻ではありません。

手動メモリ管理には、リソース取得初期化(RAII) パラダイムを介して自動リソース管理を可能にするという正確性の利点が 1 つあります。

これは、オブジェクトが所有する希少なシステム リソース(グラフィック リソース、ファイル ハンドル、データベース接続など) が、オブジェクトが破棄されるときに放棄される必要がある場合に発生します。つまり、リソース所有権の有効期間がオブジェクトの有効期間に結び付けられる必要があります。手動管理の言語では、オブジェクトの初期化 (コンストラクター内) 中にリソースを取得し、正確なタイミングで実行されるオブジェクトの破棄 (デストラクタ内) 中にリソースを解放することで、これを調整できます。これは、リソース取得は初期化であると呼ばれます。

これは、決定論的参照カウントでも使用できます。C++ では、この機能がさらに活用され、通常は手動のフレームワーク内でメモリの割り当て解除を自動化します。shared_ptr言語の標準ライブラリのテンプレートを使用してメモリ管理を実行するのは一般的なパラダイムです。ただし、はすべてのオブジェクト使用パターンに適しているわけではありませshared_ptrん。

このアプローチは、ほとんどのガベージ コレクション言語 (特にトレース ガベージ コレクターやより高度な参照カウント) では使用できません。これは、ファイナライズが非決定的であり、まったく行われないこともあるためです。つまり、ファイナライザメソッドが呼び出されるかどうか、またはいつ呼び出されるか定義 (または決定) することが困難です。これは一般にファイナライザ問題として知られています。ガベージ コレクターを実装する Java およびその他の言語では、メモリ以外の希少なシステム リソースを、 dispose パターンを介して手動で管理することがよくあります。リソースを管理するオブジェクトはすべてdispose()、そのようなリソースを解放し、オブジェクトを非アクティブとしてマークする メソッドを実装することが期待されます。プログラマーは、dispose()希少なグラフィック リソースの「リーク」を防ぐために、必要に応じて を手動で呼び出すことが期待されます。スタック リソース (単一のコード ブロック内で取得および解放されるリソース) の場合、これは、Python のwith、C# のusing、または Java のtry-with-resources などのさまざまな言語構成要素によって自動化できます。

手動メモリ管理の支持者の多くは、ガベージ コレクションなどの自動技術と比較して、手動メモリ管理の方がパフォーマンスが優れていると主張しています。従来はレイテンシが最大の利点でしたが、これはもはや当てはまりません。手動割り当ては、参照の局所性が優れていることがよくあります。^[要出典]

手動割り当ては、メモリが希少なリソースであるシステムでは、より高速に再利用できるため、より適切であることが知られています。プログラムのワーキング セットのサイズが使用可能なメモリのサイズに近づくと、メモリ システムは頻繁に「スラッシング」を起こす可能性があり、実際に起こっています。ガベージ コレクションされたシステムでは、未使用のオブジェクトはすぐに再利用されないため、手動で管理されるシステムよりも長い間、再利用されない状態のままになり、有効なワーキング セット サイズが増加します。

手動管理には、パフォーマンス上の欠点が数多くあることが文書化されています。

• などの呼び出しはdelete、実行されるたびにオーバーヘッドが発生しますが、このオーバーヘッドはガベージ コレクション サイクルで償却できます。これは、削除呼び出しを同期する必要があるマルチスレッド アプリケーションに特に当てはまります。
• 割り当てルーチンはより複雑になり、遅くなる可能性があります。ヒープ圧縮などの一部のガベージ コレクション スキームでは、フリー ストアを単純なメモリ配列として維持できます (手動管理スキームに必要な複雑な実装とは対照的です)。

レイテンシは議論の的となっているポイントであり、時間の経過とともに変化してきました。初期のガベージ コレクターと単純な実装では、手動のメモリ管理に比べてパフォーマンスが非常に劣っていましたが、洗練された最新のガベージ コレクターでは、手動のメモリ管理と同等かそれ以上のパフォーマンスを発揮することがよくあります。^{[引用が必要]}

手動割り当てでは、単純なストップ・ザ・ワールド・ガベージ・コレクションで発生する長い「一時停止」時間の影響を受けませんが、最近のガベージ・コレクターでは、気づかないほどのコレクション・サイクルが行われます。^{[引用が必要]}

手動メモリ管理とガベージ コレクションはどちらも、割り当て解除時間が無制限になる可能性があるという問題があります。手動メモリ管理では、単一のオブジェクトの割り当て解除にそのメンバーの割り当て解除、さらにそのメンバーの割り当て解除などが必要になる場合がありますが、ガベージ コレクションではコレクション サイクルが長くなる可能性があります。これは特にリアルタイム システムで問題になります。リアルタイムシステムでは、無制限のコレクション サイクルは一般に受け入れられません。リアルタイム ガベージ コレクションはガベージ コレクターを一時停止することで可能ですが、リアルタイムの手動メモリ管理では、大量の割り当て解除を回避するか、割り当て解除を手動で一時停止する必要があります。

• Berger, ED; Zorn, BG; McKinley, KS (2002 年 11 月)。「カスタム メモリ割り当ての再検討」(PDF) 。オブジェクト指向プログラミング、システム、言語、アプリケーションに関する第 17 回 ACM SIGPLAN 会議の議事録。OOPSLA '02 。pp . 1–  12。CiteSeerX 10.1.1.119.5298。doi :  10.1145/582419.582421。ISBN 1-58113-471-1。

• メモリ管理 § 手動メモリ管理

• メモリ管理リファレンス
• リチャード・ジョーンズ、ラファエル・リンス著『ガベージコレクション：自動動的メモリ管理アルゴリズム』、Wiley and Sons (1996)、ISBN 0-471-94148-4