我遇到以下報價「Desctructors不保證被調用。」這讓我感到害怕。破壞者不保證被稱爲
它繼續說，即使try finally finally塊也會中斷，導致內存泄漏。 它通過將您的代碼放入CER（受限執行區域）或從CriticalFinalizerObject派生出解決方案。
我的問題是
CriticalFinalizerObject的tradoffs，如果有的話？CriticalFinalizerObject得到真的有用嗎？你爲什麼依賴於desctructors？大多數時候你不需要它們。
也許看看IDisposeable和Dispose模式。
這裏說helpes我理解這個問題的一些鏈接
- >Everybody thinks about garbage collection the wrong way
- >How To implement dispose Pattern
- >Implementing Finalize and Dispose to Clean Up Unmanaged Resources
我知道IDisposable類做了什麼以及如何使用它，但正如我的帖子所述，這可能會中斷，導致內存泄漏。 – Jethro
好的。但是這種情況應該像其他帖子中提到的那樣用一個Try {} finally {}塊來顯式處理。 像Raymong Chen說的： >>一個正確編寫的程序不能假定終結器將永遠運行。<< –
我會重命名您的最後一個鏈接爲「如何不清理非託管資源」。非託管資源是應該使用關鍵定稿的一件事。 – CodesInChaos
我會建議使用IDisposable接口的所有資源需要銷燬，並在using區塊中使用它們。
那麼，'使用'塊（技術上）與try-finally不同呢？ （是的，這個問題很有說服力。） – Heinzi
這沒有幫助。 「使用」只是'try/finally'的語法糖。 –
關於問題3：內存泄漏通常會引起：不被釋放
不受管理的資源。對於那些使用IDisposable（在終結器中使用Dispose（）的回調函數）是最好的方法。
對由於其他對象仍然指向它們而被維護的管理對象的引用，即使它們應該被刪除。 IHMO，與垃圾收集的低級問題相比，這更像是代碼質量問題。
除非您遇到實際的內存泄漏，您甚至不應該擔心它，而不會試圖強制任何行爲。
這似乎是我得到形式人的一般答案。感謝您的回答。 – Jethro
通常，正常終結器和關鍵終結器之間的差異僅對AppDomain卸載變得重要。由於大多數非託管資源在進程卸載時自動消失，因此如果要在保持進程正常運行的同時卸載AppDomain，通常只需要擔心關鍵的終止。
我不認爲你應該爲此擔心。 –
您能否給我們鏈接到源代碼請。 –
@Jethro：'try/finally'不能被打斷，最後的代碼將會_always_運行.. @ –