分配pthread_mutex_t *使用「malloc（）」，當程序中止或退出時，它需要釋放它嗎？ 如果不是免費的話，會有問題嗎？ 只是我知道，系統將在您的進程終止時回收內存。 pthread_mutex_t可能有不好的影響？pthread_mutex_t *在程序中止或退出時是否釋放？
一樣的問題：
我的程序（文本模式的網頁瀏覽器）是動態分配內存。
當然，我在運行時會釋放不需要的塊。在正常的終止之前，我確實釋放了所有的東西 - 這樣內存泄漏檢查器就不會給我帶來誤報（如果需要進行重大的重構，請靈活處理）。
現在，我沒有做的是在異常終止之前釋放內存。 （目前，我的程序終止在信號和mallocs/reallocs失敗後。）
我的問題是：你認爲這種不好的風格？我應該釋放異常終止嗎？
我的口頭禪，（甚至是異常終止）這一切「正常終止免費一切」拿，是，通常情況下，下行空間遠遠大於上行：
1）操作系統已alreday設計，測試並由數十億用戶進行浸泡測試。在停止任何內核上的任何狀態的每個線程之後，它可以輕鬆釋放所有剩餘分配的內存。你可以用你的用戶代碼來做到這一點 - 不。
2）您必須添加代碼才能執行此操作。每次添加代碼時，都可能會添加更多的錯誤。試圖在繁忙的複雜環境中釋放所有分配的內存，多線程系統是一場噩夢，除非你是一個操作系統。內存遍佈整個地方，在線程變量，隊列等中，可能或可能不會被一個或多個線程訪問。所有權不確定且不斷變化。你會怎麼做？
3）您必須不斷測試和擴展您的關機系統，以確保在更改/增強/升級後釋放所有內存。 4）不斷檢查線程中的「終止」標誌等，以便線程可以在關閉時釋放一些內存，這是額外的開銷。
5）許多庫在關閉時並不釋放所有內存。如果圖書館是不透明/半透明的，你可能無法做任何事情。
6）如果一個線程拋出一個嚴重的異常，內存可能處於這樣一種狀態，試圖從用戶代碼中釋放它將導致其他線程中出現更多異常。
7）風險/回報 - 很好，乾淨Valgrind輸出與來自客戶的電話/電子郵件嘿，你的應用程序有時不會關閉，我們必須調用管理員來kill-9/TaskManager它。
8）過濾並計數SO re上的所有線程。 '無法阻止我的線程關閉我的應用程序'。
對於一些應用程序，一些線程可能不得不以結構化方式終止正常關機，例如，提交和關閉數據庫連接，刷新和關閉文件。釋放內存不屬於該類別，即使是正常關機。
如果您的應用程序確實存在嚴重問題，那麼您不應該嘗試「清理」內存 - 您的應用程序已經髒了，需要報廢並用新實例替換。