割り当てられた pthread_mutex_t* は「malloc()」を使用します。プログラムが中止または終了したときに解放する必要がありますか? それを解放しないと、問題が発生しますか? プロセスが終了すると、システムはメモリを再利用します。pthread_mutex_t は悪影響を与える可能性がありますか?
質問のように：
私のプログラム (テキストモードの Web ブラウザ) は動的にメモリを割り当てています。
もちろん、実行時に不要なブロックを解放します。そして、通常の終了前にすべてを解放します。これにより、メモリ リーク チェッカーが誤検知を起こさないようにします (また、主要なリファクタリングが必要になった場合に柔軟に対応できるようにします)。
今、私がしていないのは、異常終了する前にメモリを解放することです。(現在、私のプログラムはシグナルで終了し、mallocs/reallocs が失敗した後に終了します。)
私の質問は、このスタイルが悪いと思いますか? 異常終了時に解放する必要がありますか?
このすべての「正常な終了時にすべてを解放する」というマントラ (または異常な終了でさえも) に対する私の見解は、通常、マイナス面がプラス面を上回るということです。
1) OS はすでに何十億ものユーザーによって設計、テスト、浸漬テストされています。任意のコアの任意の状態のすべてのスレッドを停止した後、残りの割り当てられたメモリをすべて簡単に解放できます。ユーザーコードでこれを行うことができますか - いいえ。
2）それを行うにはコードを追加する必要があります。コードを追加するたびに、バグが増える可能性があります。OS でない限り、ビジーで複雑なマルチスレッド システムで割り当てられたすべてのメモリを解放しようとするのは悪夢です。メモリは、スレッド変数、キューなどのいたるところにあり、1 つ以上のスレッドによって現在アクセスされている場合とされていない場合があります。所有権は不確実であり、絶えず変化しています。どうする？
3) 変更/拡張/アップグレード後にすべてのメモリが解放されるように、シャットダウン システムを継続的にテストおよび拡張する必要があります。
4) スレッドがシャットダウン時にいくらかのメモリを解放できるように、スレッドの「終了」フラグなどを継続的にチェックすることは、余分なオーバーヘッドです。
5) 多くのライブラリは、閉じたときにすべてのメモリを解放しません。ライブラリが不透明/半透明の場合、何もできない可能性があります。
6) スレッドが重大な例外をスローした場合、メモリは、ユーザー コードからメモリを解放しようとすると、他のスレッドでさらに多くの例外が発生するような状態にある可能性があります。
7) リスク/報酬 - Valgrind の適切でクリーンな出力と、顧客からの電話/電子メールの対比
8) SO re のすべてのスレッドをフィルタリングしてカウントします。「アプリをシャットダウンするためにスレッドを停止できません」。
一部のアプリでは、通常のシャットダウン時に一部のスレッドを構造化された方法で終了する必要があることは避けられません。DB接続をコミットして閉じ、ファイルをフラッシュして閉じます。通常のシャットダウンの場合でも、メモリの解放はそのカテゴリには分類されません。
アプリが本当に深刻な問題を抱えている場合は、メモリを「クリーンアップ」しようとすべきではありません。アプリはすでに汚れており、破棄して新しいインスタンスに置き換える必要があります。