[解決済み] プログラム終了前にmallocの後にfreeをしないと本当に何が起こるのか？

質問

私たちは皆、割り当てられたすべてのポインタを解放しなければならないと教えられています。 しかし、メモリを解放しないことによる本当の代償について、私は少し興味があります。明らかなケースとして、たとえば malloc() がループ内部やスレッド実行の一部で呼び出された場合、メモリリークを起こさないように解放することは非常に重要なことです。 しかし、次の2つの例を考えてみてください。

まず、次のようなコードがあった場合。

int main()
{
    char *a = malloc(1024);
    /* Do some arbitrary stuff with 'a' (no alloc functions) */
    return 0;
}

ここで、実際の結果はどうなのでしょうか？ 私の考えでは、プロセスが死ぬとヒープスペースはどうせなくなるので free (しかし、私はクロージャ、保守性、および優れた実践のために、いずれにせよそれを持つことの重要性を認識しています）。 この考え方は正しいのでしょうか？

次に、シェルのような動作をするプログラムがあるとします。 ユーザーは、次のような変数を宣言することができます。 aaa = 123 そして、それらは後で使用するために何らかの動的なデータ構造に保存されます。 明らかに、何らかの*alloc関数（ハッシュマップ、リンクリスト、そのような何か）を呼び出すようなソリューションを使用することは明らかだと思われます。 この種のプログラムにおいて malloc なぜなら、これらの変数はプログラム実行中常に存在しなければならず、静的に割り当てられた領域でこれを実装する良い方法は（私が見る限り）ないからです。 メモリが割り当てられ、プロセスの終了時に解放されるだけというのは、設計上よくないのでしょうか？ もしそうなら、代替案は何でしょうか？

解決方法は？

最近のほとんどのオペレーティングシステムは、プログラムが終了した後、割り当てられたメモリ領域をすべて回復します。 唯一の例外は Palm OS のようなもので、プログラムの静的ストレージとランタイムメモリがほとんど同じものなので、解放しないことでプログラムがより多くのストレージを占有する可能性があることでしょう。 (ここでは推測に過ぎませんが)

ですから、一般的には、必要以上のストレージを持つことによるランタイムコストを除けば、何の害もありません。 確かに、あなたが挙げた例では、使用される可能性のある変数のメモリはクリアされるまで残しておきたいと考えています。

しかし、不要になったらすぐにメモリを解放し、プログラム終了時にまだ残っているものを解放するのが良いスタイルとされています。 むしろ、自分が使っているメモリを把握し、まだ必要かどうかを考える練習になります。 そうしないと、メモリーリークが発生する可能性があります。

一方、終了時にファイルをクローズするようにという同様の注意は、より具体的な結果をもたらします。そうしないと、ファイルに書き込んだデータがフラッシュされないかもしれないし、一時ファイルであれば終了時に削除されないかもしれないのです。 また、データベース・ハンドルはトランザクションをコミットし、用が済んだらクローズすべきです。 同様に、C++やObjective Cのようなオブジェクト指向言語を使っている場合、使い終わったときにオブジェクトを解放しないと、デストラクタが呼ばれず、そのクラスが担当しているリソースがクリーンアップされない可能性があります。