【正文】 .NET Resource Management Bill Wagner Effective C: 50 Specific Ways to Improve Your C， Chapter 2， .NET Resource Management， Bill Wagner， Addison Wesley Professional， 2020， 77~115 .NET 資源管理 比爾 瓦格拉 Effective C 中文版改善 C程序的 50 種方法 ，第二章， .NET 資源管理，比爾 瓦格拉， 2020， 77~115 一個簡單的事實： .Net 應(yīng)用程序是在一個托管的環(huán)境里運行的，這個環(huán)境和不同的設(shè)計器有很大的沖突，這就才有了 Effective C。極大限度上的討論這個環(huán)境的好處，須要把你對本地化環(huán)境的想法改變?yōu)?.Net CLR。也就意味著要明 1 白 .Net 的垃圾回收器。在你明白這一章里所推薦的內(nèi)容時，有必要對 .Net 的內(nèi)存管理環(huán)境有個大概的了解。那我們就開始大概的了解一下吧。 垃圾回收器 (GC)為你控制托管內(nèi)存。不像本地運行環(huán)境，你不用負(fù)責(zé)對內(nèi)存泄漏，不定指針，未初始化指針，或者一個其它內(nèi)存管理的服務(wù)問題。但 垃圾回收器前不是一個神話：你一樣要自己清理。你要對非托管資源負(fù)責(zé)，例如文件句柄，數(shù)據(jù)鏈接， GDI+對象， COM對象，以及其它一些系統(tǒng)對象。 這有一個好消息：因為 GC管理內(nèi)存，明確的設(shè)計風(fēng)格可以更容易的實現(xiàn)。循環(huán)引用，不管是簡單關(guān)系還是復(fù)雜的網(wǎng)頁對象，都非常容易。 GC的標(biāo)記以及嚴(yán)謹(jǐn)?shù)母咝惴梢詸z測到這些關(guān)系，并且完全的刪除不可達的網(wǎng)頁對象。 GC 是通過對從應(yīng)用程序的根對象開始，通過樹形結(jié)構(gòu)的 “ 漫游 ” 來斷定一個對象是否可達的，而不是強迫每個對象都保持一些引用跟蹤， COM 就是這樣的。 DataSet 就是一個很好的例 子，展示了這樣的算法是如何簡化并決定對象的所屬關(guān)系的。 DataSet是一個 DataTable 的集合，而每一個 DataTable 又是 DataRow 的集合，每一個DataRow 又是 DataItem 的集合， DataColum 定義了這些類型的關(guān)系。這里就有一些從 DataItem 到它的列的引用。而同時， DataTime 也同樣有一個引用到它的容器上，也就是 DataRow。 DataRow 包含引用到 DataTable，最后每個對象都包含一個引用到 DataSet。 如果這還不夠復(fù)雜，那可以創(chuàng)建一個 DataView，它提供對經(jīng) 過過濾后的數(shù)據(jù)表的順序訪問。這些都是由 DataViewManager 管理的。所有這些貫穿網(wǎng)頁的引用構(gòu)成了 DataSet。釋放內(nèi)存是 GC 的責(zé)任。因為 .Net 框架的設(shè)計者讓你不必釋放這些對象，這些復(fù)雜的網(wǎng)頁對象引用不會造成問題。沒有必須關(guān)心這些網(wǎng)頁對象的合適的釋放順序，這是 GC的工作。 GC 的設(shè)計結(jié)構(gòu)可以簡化這些問題，它可以識別這些網(wǎng)頁對象就是垃圾。在應(yīng)用程序結(jié)束了對 DataSet 的引用后，沒有人可以引用到它的子對象了 (譯注：就是 DataSet 里的對象再也引用不到了 )。因此，網(wǎng)頁里還有沒有對象循環(huán)引用 DataSet， DataTables 已經(jīng)一點也不重要了，因為這些對象在應(yīng)用程序都已經(jīng)不能被訪問到了，它們是垃圾了 。 垃圾回收器在它獨立的線程上運行，用來從你的程序里移除不使用的內(nèi)存。而且在每次運行時，它還會壓縮托管堆。壓縮堆就是把托管堆中活動的對象移到一起，這樣就可以空出連續(xù)的內(nèi)存。圖 展示了兩個沒有進行垃圾回收時的內(nèi)存快照。所有的空閑內(nèi)存會在垃圾回收進行后連續(xù)起來 。 2 圖 垃圾回收器不僅僅是移動不使用的內(nèi)存，還移除動其它的對象，從而壓縮使用的內(nèi)存，讓出最多的空閑內(nèi)存 。 正如你剛開始了解的，垃圾回收器的全 部責(zé)任就是內(nèi)存管理。但，所有的系統(tǒng)資源都是你自己負(fù)責(zé)的。你可以通過給自己的類型定義一個析構(gòu)函數(shù)，來保證釋放一些系統(tǒng)資源。析構(gòu)函數(shù)是在垃圾回收器把對象從內(nèi)存移除前，由系統(tǒng)調(diào)用的。你可以，也必須這樣來釋放任何你所占用的非托管資源。對象的析構(gòu)函數(shù)有時是在對象成為垃圾之后調(diào)用的，但是在內(nèi)存歸還之前。這個非確定的析構(gòu)函數(shù)意味著在你無法控制對象析構(gòu)與停止使用之間的關(guān)系 (譯注：對象的析構(gòu)與對象的無法引用是兩個完全不同的概念。關(guān)于 GC，本人推薦讀者參考一下 Jeffrey 的.Net 框架程序設(shè)計 (修訂版 )中討論的垃圾回收器 )。對 C++來說這是個重大的改變，并且這在設(shè)計上有一個重大的分歧。有經(jīng)驗的 C++程序員寫的類總在構(gòu)造函數(shù)內(nèi)申請內(nèi)存并且在析構(gòu)函數(shù)中釋放它們 ： // 好的 C++, 壞的 C: class CriticalSection { public: // 構(gòu)造系統(tǒng)需要的資源 CriticalSection( ) { EnterCriticalSection( )。 } // 銷毀資源 ~CriticalSection( ) { ExitCriticalSection( )。 } }。 // 使用 : void Func( ) 3 { // 系統(tǒng)資源的生存周期 CriticalSection s。 // Do work. //... // piler generates call to destructor. // code exits critical section. } 這是一種很常見的 C++風(fēng)格，它保證資源無異常的釋放。但這在 C里不工作，至少，與這不同。明確的析構(gòu)函數(shù)不是 .Net 環(huán)境或者 C的一部份。強行 用 C++的風(fēng)格在 C里使用析構(gòu)函數(shù)不會讓它正常的工作。在 C里，析構(gòu)函數(shù)確實是正確的運行了，但它不是即時運行的。在前面那個例子里，代碼最終在 critical section上，但在 C里，當(dāng)析構(gòu)函數(shù)存在時，它并不是在 critical section 上。它會在后面的某個未知時間上運行。你不知道是什么時候，你也無法知道是什么時候 。 依懶于析構(gòu)函數(shù)同樣會導(dǎo)致性能上的損失。須要析構(gòu)的對象在垃圾回收器上放置了一劑性能毒藥。當(dāng) GC 發(fā)現(xiàn)某個對象是垃圾但是須要析構(gòu)時，它還不能直接從內(nèi)存上刪除這個對象。首先，它要調(diào)用析構(gòu)函數(shù) ，但析構(gòu)函數(shù)的調(diào)用不是在垃圾回收器的同一個線程上運行的。取而代之的是， GC 不得不把對象放置到析構(gòu)隊列中，讓另一個線程讓執(zhí)行所有的析構(gòu)函數(shù)。 GC 繼續(xù)它自己的工作，從內(nèi)存上移除其它的垃圾。在下一個 GC 回收時，那些被析構(gòu)了的對象才會再從內(nèi)存上移除。圖 展示了三個內(nèi)存使用不同的 GC 情況。注意，那些須要析構(gòu)的對象會待在內(nèi)存里，直到下一次 GC回收 。 4 圖 這個順序展示了析構(gòu)函數(shù)在垃圾回收器上起的作用。對象會在內(nèi)存里存在的時間更長，須要啟動另一個線程來運行垃圾回收器 。 這用使你相信：那些須要析構(gòu)的對象在內(nèi)存至 少多生存一個 GC 回收循環(huán)。但，我是簡化了這些事。實際上，因為另一個 GC的介入 (譯注：其實只有一個 GC，作者是想引用回收代的問題。 )，使得情況比這復(fù)雜得多。 .Net 回收器采用 ” 代 “ 來優(yōu)化這個問題。代可以幫助 GC來很快的標(biāo)識那些看上去看是垃圾的對象。所以從上一次回后開始創(chuàng)建的對象稱為第 0 代對象，所有那些經(jīng)過一次 GC 回收后還存在的對象稱為第 1代對象。所有那些經(jīng)過 2次或者 2次以上 GC 回收后還存在的對象稱為第 2 代對象 。 分代的目的就是用來區(qū)分臨時變量以及一些應(yīng)用程序的全局變量。第 0代對象很可能是臨時的變量。成員變量， 以及一些全局變量很快會成為第 1代對象，最終成為第 2 代對象 。 GC通過限制檢測第 1以及第 2代對象來優(yōu)化它的工作。每個 GC循環(huán)都檢測第 0 代對象。粗略假設(shè)個 GC 會超過 10 次檢測來檢測第 0代對象，而要超過 100次來檢測所有對象。再次考慮析構(gòu)函數(shù)的開銷：一個須要析構(gòu)函數(shù)的對象可能要比一個不用析構(gòu)函數(shù)的對象在內(nèi)存里多待上 9 個 GC 回收循環(huán)。如果它還沒有被析構(gòu)，它將會移到第 2代對象。在第 2代對象中，一個可以生存上 100 個 GC 循環(huán)直到下一個第 2 代集合 。 結(jié)束時，記得一個垃圾回收器負(fù)責(zé)內(nèi)存管理的托管環(huán)境的最大好處：內(nèi)存泄漏，其 它指針的服務(wù)問題不在是你的問題。非內(nèi)存資源迫使你要使用析構(gòu)函數(shù)來確保清理非內(nèi)存資源。析構(gòu)函數(shù)會對你的應(yīng)用程序性能產(chǎn)生一些影響，但你必須使用它們來防止資源泄漏 (譯注：請注意理解非內(nèi)存資源是什么，一般是指文件句柄，網(wǎng)絡(luò)資源，或者其它不能在內(nèi)存中存放的資源 )。通過實現(xiàn) IDisposable 接口來避免析構(gòu)函數(shù)在垃圾回收器上造成的性能損失。接下來的具體的原則將會幫助你更有效的使用環(huán)境來開發(fā)程序 。 Effective C 原則 12：選擇變量初始化而不是賦值語句 一些類經(jīng)常不只一個構(gòu)造函數(shù)。時間一長，就難得讓它的成員變 量以及構(gòu)造函數(shù)進行同步了。最好的確保這樣的事不會發(fā)生的方法就是：在聲明就是的時間就直接初始化，而不是在每個構(gòu)造函數(shù)內(nèi)進行賦值。而且你應(yīng)該使用初始化器語法同時為靜態(tài)的和實例的變量進行初始化 。 在 C里，當(dāng)你聲明一個變量時就自然的構(gòu)造了這個成員變量。直接賦值： public class MyClass { // declare the collection, and initialize it. 5 private ArrayList _coll = new ArrayList( )。 } 忽略你最終會給 MyClass 添加多少個構(gòu)造函數(shù)， _coll 會正確的初始化。編譯器會產(chǎn)生一些代碼，使得在你的任何一個構(gòu)造函數(shù)調(diào)用前，都會初始化你聲明的實例變量。當(dāng)你添加一個新的構(gòu)造函數(shù)時， _coll 就給你初始化了。當(dāng)你添加了一個新的變量，你不用在所有的構(gòu)造函數(shù)里添加初始化代碼；直接在聲明的地方對它進行初始化就行了。同樣重要的是：如果你沒有明確的聲明任何一個構(gòu)造函數(shù)，編譯會默認(rèn)的給你添加一個，并且把所有的變量初始化過程都添加到這個構(gòu)造函數(shù)里 。 初始化器更像是一個到構(gòu)造函數(shù)的方便的快捷方法。初始化生成的代碼會放置在類型的構(gòu)造函數(shù) 之前。初始化會在執(zhí)行類型的基類的構(gòu)造函數(shù)之前被執(zhí)行，并且它們是按你聲明的先后關(guān)系順序執(zhí)行的 。 使用初始化器是一個最簡單的方法，在你的類型里來避免使用一些沒有賦值的變量，但這并不是很好。下面三種情況下，你不應(yīng)該使用初始化器語法。首先就是，如果你是初始化一個對象為 0，或者為 null。系統(tǒng)默認(rèn)會在你任何代碼執(zhí)行前，為所有的內(nèi)容都初始化為 0。系統(tǒng)置 0的初始化是基于底層的 CPU 指令，對整個內(nèi)存塊設(shè)置。你的任何其它置 0的初始化語句是多余的。 C編譯器忠實的添加額外的指令把內(nèi)存設(shè)置為 0。這并沒有錯，只是效率不高。事實上， 如果是處理值類型數(shù)據(jù)，這是很不值的 ： MyValType _MyVal1。 // initialized to 0 MyValType _MyVal2 = new MyValType()。 // also 0 兩條