一起談.NET技術，.Net Discovery系列-深入了解平台機制與性能影響(上)

　　轉眼間《.Net Discovery》系列文章已經推出1年了，本文為該系列的第10-13篇文章，在本文中将對以前所講的.Net平台知識做一個小小的總結與機制分析，引出并重點介紹這些機制對程式性能的影響與改進建議。

　　本文将分為四部分，分别講述了：垃圾回收機制、即時編譯機制、異常處理機制、字元串駐駐留機制的原理與性能改進建議。

　　《.Net Discovery》系列的每篇文章撰寫耗時都在2天以上，轉載時麻煩著名作者Aicken(李鳴)，并且未經作者同意，禁止一切商業用途！

　　一.關于垃圾回收機制●

　　機制分析垃圾收集器是.Net平台的一個特性，它自動回收托管堆上不再使用的對象，及時清理記憶體,這一切都是對開發人員透明的，當然你也可以手動把它召喚出來，它的本質就是跟蹤所有被引用到的對象，整理對象不再被引用的對象，回收相應的記憶體。垃圾收集機制采用标記與清除(Mark Sweep)算法來完成上述任務，整個過程分為兩步：

　　Step 1.Mark-Sweep ：從應用程式的root出發，利用互相引用關系，周遊其在Heap上動态配置設定的所有對象，指明需要回收的對象，标記出那些存活的對象，予以标記。

　　Step 2.Compact： 對記憶體中存活的對象進行移動，修改它們的指針，使之在記憶體中連續，這樣空閑的記憶體也就連續了，即完成了記憶體釋放工作，也解決了記憶體碎片問題，這個過程也可以成為指針的壓縮。垃圾收集器一般将托管堆中的對象分為3代，這可以通過調用GC.MaxGeneration得知，對象按照存在時間長短進行分代，最短的分在第0代，最長的分在第2代，第2代中的對象往往是比較大的，第二代空間被稱作Large Object Heap，對于2代對象的回收，與第0、1代回收方式相比最大的不同在于，沒有了指針移動的壓縮過程。如下圖，第一次GC時，左邊第一列A-F表示記憶體中的對象，位于淺藍色 區域，經過Mark後，ACDF标記為可用，Sweep過程清除了BE，Compact過程移動了ACDF，使之位于連續存儲區域中；第二次使用綠色做标記；第三次GC使用藍色表示标記；可以看出第三次GC過程沒有了指針移動的壓縮過程。

圖1 對象的回收

　　●性能影響分析這個過程看起來有點複雜，的确垃圾收集器的啟動是會占用一些CPU時間，進而影響系統的性能，但這種影響很有限，并且這些損失是有所值的。

　　1.垃圾收集器并不是沒有規律的啟動，而是當代齡達到一定觸發條件時啟動，而且垃圾收集器隻是移動代齡較低的1、2代的資源，并不會移動LOH中的對象。這就在一定程度上避免了GC長時間鎖定線程導緻的性能損失。

　　2.GC有三種不同的工作模式，适用于不同環境的情況，并不是所有環境都是使用挂起-查找與标記-壓縮-恢複 的流程。Workstation GC with Concurrent模式可以第0、1代的收集仍然是要暫時挂起應用程式，在收集第2代時，會并行處理，具體原理是将Full GC過程切分成多個短暫子過程對線程進行當機，線上程當機時間之外，應用程式仍然可以正常運作。

　　這主要通過将0代空間設定的很大，使Full GC時，CLR仍然能夠在0代中進行記憶體配置設定，如果Full GC時0代記憶體也已用盡，那麼應用程式将被挂起，等待Full GC的完成。在多CPU的情況下，可以使用和Server GC模式。這種GC模式有着很高的性能和效率。

　　這種模式下，CLR為每個CPU建立一個專用的GC線程，每個CPU可以獨立的為相應的heap執行GC操作，這些GC線程是以非并發的形式工作的，收集工作與線程正常工作不能同時進行，這就是說第0、1、2代的收集都會挂起應用線程。在.Net 4.0中，有一種新的垃圾收集機制，叫做背景收集。這種機制以concurrent GC為基礎的，如上文所講，Workstation GC with Concurrent模式中，在Full GC過程時，CLR仍然能夠在0代中進行記憶體配置設定，如果Full GC時0代記憶體也已用盡，那麼應用程式将被挂起，等待Full GC的完成。

　　3.垃圾收集器是配合政策引擎工作的。政策引擎可以喚醒GC，它會根據GC啟動的次數、頻率、代齡情況等自發的啟動GC，使GC工作。特别要注意的是，由程式人員手動的調用GC收集的代碼，同樣會影響政策引擎的工作，這樣會給政策引擎錯誤的信号，進而導緻GC的錯誤啟動，是以在沒有必要的情況下，一般不建議使用GC.Collect();手動回收。

　　● 綜述比起垃圾收集器帶來的微乎的性能損失，我們應該把精力放在程式的優化上，非托管資源的及時釋放、字元串拼接、循環内的業務代碼都是需要注意的地方。垃圾收集機制不是.Net也不是Java的專利，它已經有一段進化的曆史，越來越多的案例也證明垃圾收集機制的優點，Exchange 2010的大部分子產品就是基于托管環境的。

　　二.關于實時編譯機制JIT（Just In Time簡稱JIT）是.Net邊運作邊編譯的一種機制，這種機制的命名來源于豐田汽車在20世紀60年代實行的一種生産方式，中文譯為準時制。.Net 的JIT編譯器在設計初衷和運作方式來上講，都與豐田汽車的這種準時生産思想體系有着很大的相似之處，是以讓我們先來透過準時生産方式來了解.Net的JIT機制吧。

　　準時生産的基本思想可概括為在需要的時候，按需要的量生産所需的産品，這正是.Net JIT編譯器的設計初衷，即在需要的時候編譯需要的代碼。