.Net平台GC VS JVM垃圾回收

.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會在不需要時自動釋放記憶體空間。

垃圾回收可以安全地處理記憶體配置設定，是以沒有對象會錯誤地使用另一個對象的内容。

新建立的對象的構造函數不必初始化所有資料字段，因為垃圾回收會清除以前釋放的對象的記憶體。

非托管堆

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

在定義類時聲明析構函數。

在定義類時實作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

原文位址

https://www.cnblogs.com/sword-successful/p/12808770.html