atexit() 関数でメモリを解放するポイントはありますか?
起動後に malloc されるグローバル変数があります。atexit() 関数を記述して解放することもできますが、プログラムが終了したときに、システムはそのメモリをすべて再利用するのではないでしょうか?
自分で片付けて積極的に掃除することに何かメリットはありますか?
C ではありません - 船があなたの周りで沈んでいる間にデッキチェアを再配置するようなものです.
C++ では答えが異なります。オブジェクトはデストラクタで一時ファイルなどを削除できるため、それらが確実に呼び出されるようにする必要があります。
それを解放する利点の 1 つは、プロセスの存続期間にわたって割り当てと解放を一致させようとするメモリ リーク テストを行った場合、この種の意図的なリークによる誤検知が発生しないことです。
malloc()
/free()
通常、ユーザー空間に存在する広範なデータ構造を含むと見なすと、プログラムfree()
の終了時にメモリを使用すると、実際にはパフォーマンスが低下する可能性があります。データ構造の一部がディスクにページングされている場合、ディスクからロードする必要があるのは破棄するためだけです!
free()
一方、 ingを使用せずに終了すると、ディスクにページアウトされたデータは問題なく終了する可能性があります。
もちろん、解放したスペースをさらに s で再利用でき、一部のメモリのマップを解除して他のプロセスで使用できるようになる可能性があるため、free()
他のときに ing を使用することは通常有益です。malloc()
free()
最新のすべてのオペレーティング システムでは、プログラムの終了時にすべてのメモリが解放されると想定しても問題ありません。
プログラムが進化するとき、実際に整頓することは興味深いかもしれません。それはあなたが「初期化」関数を作成するときにクリーンアップ関数を書くことを強制します。プログラムがより複雑になり、プログラムの一部を再起動したい場合にメリットがあります。動作するクリーンアップ関数をすでに作成している場合は、プログラムの一部を「再起動」するときに突然クリーンアップを忘れる可能性は低くなります。
クリーンアップ関数を「怠惰に」作成します。つまり、必要な場合にのみ、エラーが発生しやすくなります。クリーンアップ関数を作成すると、クリーンアップと最終的なクリーンアップの依存関係について考える必要があります。これにより、コードの一部を別のプロジェクトで簡単に再利用できます。
したがって、atexitで解放することは無意味であり、ファイル記述子を閉じることも無意味です。ただし、コードが大きくなるにつれてクリーンアップ関数を記述して維持することは、自分が何をしているかについて考えることを余儀なくされる制約になる可能性があります。
atexit()を呼び出すコードが動的にロードされる共有ライブラリの一部である場合(たとえば、dlopen()を使用)、free()を実行する必要があります。この場合、atexitハンドラーはdlclose()時に呼び出されるため、残りのプロセスで使用するためにヒープが存在し続けます。
Windows では、OS または COM に属するメモリを返す呼び出しがあり、そのメモリを明示的に解放する必要があります。そうしないと、プロセスが終了した後でも解放されません。しかし、これはまれなシナリオです。
プロセスが終了する前にメモリを解放しないことは、メモリ リークではありません。ハンドルを失うと、メモリリークになります。ただし、リソースの種類はメモリだけではなく、他のリソース (ウィンドウ ハンドルやファイル ハンドルなど) がプロセス間で存続するため、それらを「解放」する必要があります。