.Net平台GC VS JVM垃圾回收

前言

不知道你平時是否關注程序內存使用情況，我是關注的比較少，正好借着優化本地一個程序的空對比了一下.Net平台垃圾回收和jvm垃圾回收，順便用dotMemory看了程序運行后的內存快照，生成內存快照后，媽媽再也不擔心我優化程序找不到方向了。

.Net平台垃圾回收

內存優化

憑空想象這些概念多少會索然無味，下圖是我我基於本地的一個程序生成的內存快照，使用jetbrains推出的dotMemory工具生成。

生成內存快照

程序運行時可以通過右上角的Get SnapShot按鈕生成內存快照，內存快照里可以看到具體的對象、消耗內存的情況，比如說一些大的字符串對象，重復的大量的字符串對象， 那么從上面這張圖上都能看到哪些關鍵字呢？
什么是Heap generation1和Heap greneration2呢？
什么是Allocated呢？

什么是GC

GC (Garbage Collection)如其名，就是垃圾收集，當然這里僅就內存而言。Garbage Collector（垃圾收集器，在不至於混淆的情況下也成為GC）以應用程序的root為基礎，遍歷應用程序在托管堆(Managed Heap)上動態分配的所有對象，通過識別它們是否被引用來確定哪些對象是已經死亡的、哪些仍需要被使用。已經不再被應用程序的root或者別的對象所引用的對象就是已經死亡對象，即所謂的垃圾，需要被回收。這就是GC工作的原理。為了實現這個原理，GC有多種算法。比較常見的算法有Reference Counting，Mark Sweep，Copy Collection等等。目前主流的虛擬系統.NET CLR，JVM都是采用的Mark Sweep算法。

Mark-Compact 標記壓縮算法

簡單地把.NET的GC算法看作Mark-Compact算法。階段1: Mark-Sweep 標記清除階段，先假設heap中所有對象都可以回收，然后找出不能回收的對象，給這些對象打上標記，最后heap中沒有打標記的對象都是可以被回收的；階段2: Compact 壓縮階段，對象回收之后heap內存空間變得不連續，在heap中移動這些對象，使他們重新從heap基地址開始連續排列，類似於磁盤空間的碎片整理。
     


        Heap內存經過回收、壓縮之后，可以繼續采用前面的heap內存分配方法，即僅用一個指針記錄heap分配的起始地址就可以。主要處理步驟：將線程掛起→確定roots→創建reachable objects graph→對象回收→heap壓縮→指針修復。可以這樣理解roots：heap中對象的引用關系錯綜復雜（交叉引用、循環引用），形成復雜的graph，roots是CLR在heap之外可以找到的各種入口點。
        GC搜索roots的地方包括全局對象、靜態變量、局部對象、函數調用參數、當前CPU寄存器中的對象指針（還有finalization queue）等。主要可以歸為2種類型：已經初始化了的靜態變量、線程仍在使用的對象（stack+CPU register） 。 Reachable objects：指根據對象引用關系，從roots出發可以到達的對象。例如當前執行函數的局部變量對象A是一個root object，他的成員變量引用了對象B，則B是一個reachable object。從roots出發可以創建reachable objects graph，剩余對象即為unreachable，可以被回收。
    
           指針修復是因為compact過程移動了heap對象，對象地址發生變化，需要修復所有引用指針，包括stack、CPU register中的指針以及heap中其他對象的引用指針。Debug和release執行模式之間稍有區別，release模式下后續代碼沒有引用的對象是unreachable的，而debug模式下需要等到當前函數執行完畢，這些對象才會成為unreachable，目的是為了調試時跟蹤局部對象的內容。傳給了COM+的托管對象也會成為root，並且具有一個引用計數器以兼容COM+的內存管理機制，引用計數器為0時，這些對象才可能成為被回收對象。Pinned objects指分配之后不能移動位置的對象，例如傳遞給非托管代碼的對象（或者使用了fixed關鍵字），GC在指針修復時無法修改非托管代碼中的引用指針，因此將這些對象移動將發生異常。pinned objects會導致heap出現碎片，但大部分情況來說傳給非托管代碼的對象應當在GC時能夠被回收掉。

垃圾回收之三個階段

• Marking Phase：在標記階段會創建所有活動對象的列表。 這是通過遵循所有根對象的引用來完成的。 不在活動對象列表中的所有對象都可能從堆內存中刪除。
• Relocating Phase：所有活動對象列表中所有對象的引用在重定位階段進行更新，以便它們指向在壓縮階段將對象重定位到的新位置。
• Compacting Phase：隨着釋放死亡對象占用的空間並移動剩余的活動對象，堆會在壓縮階段被壓縮。 垃圾回收后剩余的所有活動對象均按其原始順序移至堆內存的較舊端。

垃圾回收之Genearation - 分代

堆內存在回收過程中不是一次性回收所有，而是分為3代，目前也支持3代，根據上面的截圖可以看出來。因此可以在垃圾回收期間適當地處理具有不同生存期的各種對象。 取決於項目的大小，每一代的內存將由公共語言運行時（CLR）給出。 在內部，Optimization Engine將調用Collection Means方法來選擇哪些對象將進入第1代或第2代。

• Generation 0：所有短期對象（例如臨時變量）都包含在堆內存的第0代中。 除非它們是大對象，否則所有新分配的對象也是隱式的第0代對象。 通常，垃圾回收的頻率在第0代中最高。
• Generation 1：如果運行在垃圾回收中未釋放的第0代對象占用的空間，則這些對象將移至第1代。這一代中的對象是第0代中的短期對象和第2代中的長期對象之間的一種緩沖區對象。
• Generation 2：如果某個第1代對象占用的空間未在下一次垃圾回收運行中釋放，則這些對象將移至第2代。第2代對象的生存期很長，例如靜態對象，因為它們整個都保留在堆內存中 處理持續時間。

GC給我們帶來的優勢

• 垃圾回收使用3個代的概念成功的在托管堆上有效的分配對象內存。
• 不再需要手動釋放內存，GC會在不需要時自動釋放內存空間。
• 垃圾回收可以安全地處理內存分配，因此沒有對象會錯誤地使用另一個對象的內容。
• 新創建的對象的構造函數不必初始化所有數據字段，因為垃圾回收會清除以前釋放的對象的內存。

非托管堆

說了半天都在說托管堆，那么非托管堆呢？垃圾回收是不知道什么時候去處理非托管堆資源，比如文件句柄，網絡連接、數據庫連接。以下兩種方式用來處理非托管堆垃圾回收。

1. 在定義類時聲明析構函數。
2. 在定義類時實現IDisposable接口並實現Dispose函數， 實現接口有在程序中有兩種處理方法，使用using關鍵字，推薦使用， 再就是在finally中顯式調用Dispose函數。

附錄GC常用函數

返回指定對象的當前代數
public static int GetGeneration(Object);

檢索當前認為要分配的字節數。 一個參數，指示此方法是否可以等待較短間隔再返回，以便系統回收垃圾和終結對象
public static long GetTotalMemory (bool forceFullCollection);

返回已經對對象的指定代進行的垃圾回收次數。
public static int CollectionCount (int generation);

獲取垃圾回收的內存信息
public static GCMemoryInfo GetGCMemoryInfo ();

強制對所有代進行即時垃圾回收。
public static void Collect ();

jvm垃圾回收

好吧，說到這里還沒提出來jvm垃圾回收，如果你已經了解了jvm垃圾回收，從上面的垃圾回收算法和分代回收來看，.Net平台和jvm在垃圾回收這塊設計思路是一致的，兩者的垃圾回收算法都包含：標記清除算法、復制算法、標記整理算法、分代收集算法。 
       ** 當前商業虛擬機算法都使用分代收集算法，jvm根據對象的存活周期把內存划分為：年輕代、老年代、永久代。

新生代（Young generation）

絕大多數最新被創建的對象會被分配到這里，由於大部分對象在創建后會很快變得不可達，所以很多對象被創建在新生代，然后消失。對象從這個區域消失的過程我們稱之為 minor GC。
新生代 中存在一個Eden區和兩個Survivor區.新對象會首先分配在Eden中（如果新對象過大，會直接分配在老年代中）。在GC中，Eden中的對象會被移動到Survivor中，直至對象滿足一定的年紀（定義為熬過GC的次數），會被移動到老年代。
可以設置新生代和老年代的相對大小。這種方式的優點是新生代大小會隨着整個堆大小動態擴展。參數 -XX:NewRatio 設置老年代與新生代的比例。例如 -XX:NewRatio=8 指定 老年代/新生代 為8/1. 老年代 占堆大小的 7/8 ，新生代 占堆大小的 1/8（默認即是 1/8）。
例如：

-XX:NewSize=64m -XX:MaxNewSize=1024m -XX:NewRatio=8

老年代（Old generation）

對象沒有變得不可達，並且從新生代中存活下來，會被拷貝到這里。其所占用的空間要比新生代多。也正由於其相對較大的空間，發生在老年代上的GC要比新生代要少得多。對象從老年代中消失的過程，可以稱之為major GC（或者full GC）。

永久代（permanent generation）

像一些類的層級信息，方法數據 和方法信息（如字節碼，棧 和 變量大小），運行時常量池（JDK7之后移出永久代），已確定的符號引用和虛方法表等等。它們幾乎都是靜態的並且很少被卸載和回收，在JDK8之前的HotSpot虛擬機中，類的這些"永久的" 數據存放在一個叫做永久代的區域。
永久代一段連續的內存空間，我們在JVM啟動之前可以通過設置-XX:MaxPermSize的值來控制永久代的大小。但是JDK8之后取消了永久代，這些元數據被移到了一個與堆不相連的稱為元空間 (Metaspace) 的本地內存區域。

小結

JDK8堆內存一般是划分為年輕代和老年代，不同年代 根據自身特性采用不同的垃圾收集算法。
對於新生代，每次GC時都有大量的對象死亡，只有少量對象存活。考慮到復制成本低，適合采用復制算法。因此有了From Survivor和To Survivor區域。
對於老年代，因為對象存活率****高，沒有額外的內存空間對它進行擔保。因而適合采用標記-清理算法和標記-整理算法進行回收。

總結

目前對比了.Net平台垃圾回收和jvm垃圾回收，對於垃圾回收算法和分代的概念，兩者設計思路都相同，唯一的區別我個人覺的JDK8以后jvm的垃圾回收效率更高，根據不同的代使用不同的垃圾收集算法，這一點似乎是.Net平台垃圾回收沒有實現的地方。

參考鏈接

https://www.geeksforgeeks.org/garbage-collection-in-c-sharp-dot-net-framework/
https://juejin.im/post/5b4dea755188251ac1098e98
https://kb.cnblogs.com/page/106720/
https://www.zhihu.com/question/31806845