.Net平臺GC VS JVM垃圾回收_ZenDei技術網路在線

前言不知道你平時是否關註程式記憶體使用情況，我是關註的比較少，正好藉著優化本地一個程式的空對比了一下.Net平臺垃圾回收和jvm垃圾回收，順便用dotMemory看了程式運行後的記憶體快照，生成記憶體快照後，媽媽再也不擔心我優化程式找不到方向了。 .Net平臺垃圾回收記憶體優化憑空想象這些概念多少會索 ...

前言

不知道你平時是否關註程式記憶體使用情況，我是關註的比較少，正好藉著優化本地一個程式的空對比了一下.Net平臺垃圾回收和jvm垃圾回收，順便用dotMemory看了程式運行後的記憶體快照，生成記憶體快照後，媽媽再也不擔心我優化程式找不到方向了。

.Net平臺垃圾回收

記憶體優化

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

生成記憶體快照

QQ截圖20200422180141.png
程式運行時可以通過右上角的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會在不需要時自動釋放記憶體空間。
垃圾回收可以安全地處理記憶體分配，因此沒有對象會錯誤地使用另一個對象的內容。
新創建的對象的構造函數不必初始化所有數據欄位，因為垃圾回收會清除以前釋放的對象的記憶體。

非托管堆

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

在定義類時聲明析構函數。
在定義類時實現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區域。
對於老年代，因為對象存活率****高，沒有額外的記憶體空間對它進行擔保。因而適合採用標記-清理演算法和標記-整理演算法進行回收。