メモリリークはどこまで行くことができますか？

メモリリークに何度も遭遇しました。通常、私はmalloc明日がないようなとき、またはFILE *汚れた洗濯物のようにぶら下がっているとき。私は通常、少なくともプログラムが終了したときにすべてのメモリがクリーンアップされると想定しています（読む：必死に願っています）。プログラムの終了時やクラッシュ時に、リークされたメモリが収集されない状況はありますか？

答えが言語によって大きく異なる場合は、C（++）に焦点を当てましょう。

「明日がないような」、「汚れた洗濯物のようにぶら下がっている」などの語句の双曲線の使用に注意してください。安全ではない* malloc*あなたが愛する人を傷つける可能性があります。また、汚れた洗濯にはご注意ください。

いいえ。オペレーティングシステムは、プロセスが終了すると、プロセスが保持していたすべてのリソースを解放します。

これは、オペレーティングシステムが維持するすべてのリソースに適用されます：メモリ、開いているファイル、ネットワーク接続、ウィンドウハンドル...

とはいえ、プログラムがオペレーティングシステムのない組み込みシステム、または非常に単純またはバグのあるオペレーティングシステムで実行されている場合、メモリは再起動するまで使用できなくなる可能性があります。しかし、もしあなたがそのような状況にあったなら、あなたはおそらくこの質問をすることはないでしょう。

オペレーティングシステムは、特定のリソースを解放するのに長い時間がかかることがあります。たとえば、ネットワークサーバーが接続を受け入れるために使用するTCPポートは、プログラムによって適切に閉じられていても、解放されるまでに数分かかる場合があります。ネットワーク化されたプログラムは、データベースオブジェクトなどのリモートリソースも保持できます。リモートシステムは、ネットワーク接続が失われたときにこれらのリソースを解放する必要がありますが、ローカルオペレーティングシステムよりもさらに時間がかかる場合があります。

C標準はmalloc、プログラムの終了時にによって割り当てられたメモリが解放されることを指定していません。これはオペレーティングシステムによって行われ、すべてのOS（通常、これらは組み込み環境にある）ではなく、プログラムの終了時にメモリを解放します。

すべての回答は、最新のOSに関する質問のほとんどの側面をカバーしていますが、歴史的に、これまでDOSの世界でプログラミングしたことがある場合に言及する価値のあるものがあります。ターミナントアンドステイレジデント（TSR）プログラムは通常、システムに制御を返しますが、ソフトウェア/ハードウェアの割り込みによって回復できるメモリに常駐します。次のようなメッセージが表示されるのは正常ですこれらのOSで作業しているときに、「メモリ不足です！TSRの一部をアンロードしてみてください」です。

だから技術的には プログラムは終了しますがプログラムはまだメモリ上にあるため、プログラムをアンロードしない限り、メモリリークは解放されません。

つまり、バグがあるか、組み込みOSがそうするように設計されているために、OSがメモリを再利用しないこととは別に、これを別のケースと考えることができます。

もう一つ例を覚えています。主にIBMメインフレームで実行されるトランザクションサーバーである顧客情報管理システム（CICS）は、疑似会話型です。実行されると、ユーザーが入力したデータを処理し、ユーザー用の別のデータセットを生成し、ユーザーターミナルノードに転送して終了します。アテンションキーをアクティブにすると、再び復活して別のデータセットを処理します。技術的には、その動作方法のため、CICSトランザクションサーバーをリサイクルしない限り、OSは終了したCICSプログラムからメモリを再利用しません。

他の人が言ったように、ほとんどのオペレーティングシステムは、プロセスの終了時に割り当てられたメモリ（およびおそらくネットワークソケット、ファイルハンドルなどの他のリソース）を再利用します。

そうは言っても、（生のmalloc / freeの代わりに）new / deleteを処理するときに心配する必要があるのはメモリだけではないかもしれません。newに割り当てられたメモリは回収される場合がありますが、オブジェクトのデストラクタで行われる可能性のあることは起こりません。おそらく、あるクラスのデストラクタは、破壊時にセンチネル値をファイルに書き込みます。プロセスが終了するだけの場合、ファイルハンドルがフラッシュされてメモリが解放されることがありますが、そのセンチネル値は書き込まれません。

物語の教訓、常に自分の後を片付ける。物事をぶら下げないでください。OSのクリーンアップに依存しないでください。自分の後片付け。

これは、言語よりもオペレーティングシステムに依存する可能性が高くなります。最終的に、どの言語のどのプログラムでも、オペレーティングシステムからメモリを取得します。

プログラムが終了/クラッシュしたときにメモリをリサイクルしないオペレーティングシステムについては聞いたことがありません。したがって、プログラムが割り当てる必要のあるメモリに上限がある場合は、割り当てるだけで解放しないことは完全に合理的です。

プログラムが別のプログラムのアドレス空間に読み込まれる動的コンポーネント（「プラグイン」）に変換されると、きちんとしたメモリ管理を備えたオペレーティングシステムであっても、問題が発生します。能力の低いシステムに移植されるコードについて考える必要すらありません。

一方、すべてのメモリを解放すると、と、プログラムのクリーンアップのパフォーマンスに影響を与えるます。

私が取り組んでいる1つのプログラムでは、特定のテストケースがすべての動的メモリのグラフを再帰して1つずつ解放するため、プログラムが終了するまでに30秒以上必要でした。

妥当な解決策は、そこに機能を持たせてテストケースでカバーすることですが、アプリケーションを迅速に終了するために、プロダクションコードではオフにします。

タイトルに値するすべてのオペレーティングシステムは、終了後に行われたプロセスの混乱を解消します。しかし、常に予期しないイベントがあり、何らかの理由でアクセスが拒否され、一部の貧弱なプログラマーが可能性を予測しなかったため、少し後で再試行しない場合はどうなりますか？メモリリークがミッションクリティカルである場合は、常に自分をクリーンアップする方が常に安全です。それ以外の場合、IMOの作業にコストがかかる場合、IMOの価値はあまりありません。

編集：ループのように、メモリリークが蓄積する場所にある場合は、それらをクリーンアップする必要があります。私が話すメモリリークは、プログラムの経過を通じて一定の時間内に蓄積されるものです。他の種類のリークがある場合は、遅かれ早かれ深刻な問題になる可能性があります。

技術的には、リークがメモリの「複雑さ」O（1）である場合、ほとんどの場合問題ありません。O（logn）はすでに不快で（場合によっては致命的）、O（N）+は耐えられません。

POSIX準拠システムの共有メモリは、shm_unlinkが呼び出されるか、システムが再起動されるまで持続します。

プロセス間通信がある場合、プロトコルによっては、他のプロセスがリソースを完了および消費しないことがあります。

例を挙げれば、プリンタジョブの途中でJVMを終了したときに、JavaでPDFプリンタへの印刷を試していたところ、PDFスプールプロセスがアクティブのままであり、タスクマネージャーでそれを強制終了しないと、印刷を再試行してください。