.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/
http://www.javashuo.com/article/p-niycnocw-mk.html
https://kb.cnblogs.com/page/106720/
https://www.zhihu.com/question/31806845