新生代java

A. 深入理解GC垃圾回收機制

在我們程序運行中會不斷創建新的對象，這些對象會存儲在內存中，如果沒有一套機制來回收這些內存，那麼被佔用的內存會越來越多，可用內存會越來越少，直至內存被消耗完。於是就有了一套垃圾回收機制來做這件維持系統平衡的任務。

1.確保被引用對象的內存不被錯誤的回收
2.回收不再被引用的對象的內存空間

給對象中添加一個引用計數器，每當有一個地方引用它時，計數器值就加1；當引用失效時， 計數器值就減1；任何時刻計數器為0的對象就是不可能再被使用的。

優點：引用計數收集器可以很快地執行，交織在程序的運行之中。
缺點：很難處理循環引用，比如上圖中相互引用的兩個對象，計數器不為0，則無法釋放，但是這樣的對象存在是沒有意義的，空占內存了。

引用計數法處理不了的相互引用的問題，那麼就有了可達性分析來解決了這個問題。

從GC Roots作為起點，向下搜索它們引用的對象，可以生成一棵引用樹，樹的節點視為可達對象，反之最終不能與GC Roots有引用關系的視為不可達，不可達對象即為垃圾回收對象。

我自己的理解是，皇室家族每過一段時間，會進行皇室成員排查，從皇室第一代開始往下找血緣關系的後代，如果你跟第一代皇室沒有關系，那麼你就會被剔除皇室家族。

1.虛擬機棧中引用的對象（正在運行的方法使用到的變數、參數等）
2.方法區中類靜態屬性引用的對象（static關鍵字聲明的欄位）
3.方法區中常量引用的對象，(也就是final關鍵字聲明的欄位)
4.本地方法棧中引用的對象（native方法）

1.顯示地賦予某個對象為null，切斷可達性

在main方法中創建objectA、objectB兩個局部變數，而且相互引用。相互引用直接調System.gc()是回收不了的。而將兩者都置為null，切斷相互引用，切斷了可達性，與GCRoots無引用，那麼這兩個對象就會被回收調。

2.將對象的引用指向另一個對象

這里將one的引用也指向了two引用指向的對象，那麼one原本指向的對象就失去了GCRoots引用，這里就判斷該對象可被回收。

3.局部對象的使用

當方法執行完，局部變數object對象會被判定為可回收對象。

4.只有軟、弱、虛引用與之關聯
new出來的對象被強引用了，就需要去掉強引用，改為弱引用。被弱引用之後，需要置空來幹掉強引用，達到隨時可回收的效果。

只被軟引用的對象在內存不足的情況，可能會被GC回收掉。

只被弱引用持有的對象，隨時都可能被GC回收，該對象就為可回收對象。

是不是被判定為了可回收對象，就一定會被回收了呢。其實Ojbect類中還有一個finalize方法。這個方法是對象在被GC回收之前會被觸發的方法。

該方法翻譯過來就是：當垃圾回收確定不再有對該對象的引用時，由垃圾回收器在對象上調用。子類重寫finalize方法以處置系統資源或執行其他清除。說人話就是對象死前會給你一個迴光返照，讓你清醒一下，想干什麼就干什麼，甚至可以把自己救活。我們可以通過重寫finalize方法，來讓對象復活一下。

示例：

執行的結果：

這里我們重寫FinalizeGC類的finalize方法， 使用FinalizeGC.instance = this語句，讓對象又有了引用，不再被判定為可回收對象，這里就活了。然後再置空再回收一下，這個對象就死了，沒有再被救活了。所以finalize方法只能被執行一次，沒有再次被救活的機會。

在JDK1.8版本廢棄了永久代，替代的是元空間（MetaSpace），元空間與永久代上類似，都是方法區的實現，他們最大區別是：元空間並不在JVM中，而是使用本地內存。
元空間有注意有兩個參數：

MetaspaceSize ：初始化元空間大小，控制發生GC閾值
MaxMetaspaceSize ： 限制元空間大小上限，防止異常佔用過多物理內存
為什麼移除永久代？
移除永久代原因：為融合HotSpot JVM與JRockit VM（新JVM技術）而做出的改變，因為JRockit沒有永久代。
有了元空間就不再會出現永久代OOM問題了！

1.Generational Collection（分代收集）演算法
分代收集演算法是GC垃圾回收演算法的總綱領。現在主流的Java虛擬機的垃圾收集器都採用分代收集演算法。Java 堆區基於分代的概念，分為新生代（Young Generation）和老年代（Tenured Generation），其中新生代再細分為Eden空間、From Survivor空間和To Survivor空間。 (Survivor：倖存者)

分代收集演算法會結合不同的收集演算法來處理不同的空間，因此在學習分代收集演算法之前我們首先要了解Java堆區的空間劃分。Java堆區的空間劃分在Java虛擬機中，各種對象的生命周期會有著較大的差別。因此，應該對不同生命周期的對象採取不同的收集策略，根據生命周期長短將它們分別放到不同的區域，並在不同的區域採用不同的收集演算法，這就是分代的概念。

當執行一次GC Collection時，Eden空間的存活對象會被復制到To Survivor空間，並且之前經過一次GC Collection並在From Survivor空間存活的仍年輕的對象也會復制到To Survivor空間。

對象進入到From和To區之後，對象的GC分代年齡ege的屬性，每經過GC回收存活下來，ege就會+1，當ege達到15了，對象就會晉級到老年代。

2.Mark-Sweep（標記-清除）演算法
標記清除：標記階段的任務是標記出所有需要被回收的對象，清除階段就是回收被標記的對象所佔用的空間。標記-清除演算法主要是運用在Eden區，該區對象很容易被回收掉，回收率很高。

3.Copying（復制）演算法
復制演算法的使用在From區和To區，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活著的對象復制到另外一塊上面，然後再把已使用的內存空間一次清理掉，這樣一來就不容易出現內存碎片的問題。

缺點：可使用內存縮減為一半大小。

那麼復制演算法使可使用內存大小會減半，設計上是怎麼解決這個問題的呢。就是給From和To區劃分盡可能小的區域。經過大數據統計之後，對象在第一次使用過後，絕大多數都會被回收，所以能進入第一次復制演算法的對象只佔10%。那麼設計上，Eden、From、To區的比例是8:1:1，絕大多數對象會分配到Eden區，這樣就解決了復制演算法縮減可用內存帶來的問題。

4.Mark-Compact (標記—整理)演算法
在新生代中可以使用復制演算法，但是在老年代就不能選擇復制演算法了，因為老年代的對象存活率會較高，這樣會有較多的復制操作，導致效率變低。標記—清除演算法可以應用在老年代中，但是它效率不高，在內存回收後容易產生大量內存碎片。因此就出現了一種標記—整理演算法，與標記—清除演算法不同的是，在標記可回收的對象後將所有存活的對象壓縮到內存的一端，使它們緊湊地排列在一起，然後對邊界以外的內存進行回收，回收後，已用和未用的內存都各自一邊。

垃圾收集演算法是內存回收的方法論，那麼垃圾收集器就是內存回收的具體實現：
Serial 收集器（復制演算法): 新生代單線程收集器，標記和清理都是單線程，
優點是簡單高效；
Serial Old 收集器 (標記-整理演算法): 老年代單線程收集器，Serial 收集器
的老年代版本；
ParNew 收集器 (復制演算法): 新生代收並行集器，實際上是 Serial 收集器
的多線程版本，在多核 CPU 環境下有著比 Serial 更好的表現；
CMS(Concurrent Mark Sweep)收集器（標記-清除演算法）： 老年代並行
收集器，以獲取最短回收停頓時間為目標的收集器，具有高並發、低停頓
的特點，追求最短 GC 回收停頓時間。

B. Java垃圾回收：GC在什麼時候對什麼做了什麼

GC在什麼時候對什麼做了什麼？
要回答這個問題，先了解下GC的發展史、jvm運行時數據區的劃分、jvm內存分配策略、jvm垃圾收集演算法等知識。
先說下jvm運行時數據的劃分，粗暴的分可以分為堆區(Heap)和棧區(Stack)，但jvm的分法實際上比這復雜得多，大概分為下面幾塊：
1、程序計數器(Program Conuter Register)
程序計數器是一塊較小的內存空間，它是當前線程執行位元組碼的行號指示器，位元組碼解釋工作器就是通過改變這個計數器的值來選取下一條需要執行的指令。它是線程私有的內存，也是唯一一個沒有OOM異常的區域。
2、Java虛擬機棧區(Java Virtual Machine Stacks)
也就是通常所說的棧區，它描述的是Java方法執行的內存模型，每個方法被執行的時候都創建一個棧幀(Stack Frame)，用於存儲局部變數表、操作數棧、動態鏈接、方法出口等。每個方法被調用到完成，相當於一個棧幀在虛擬機棧中從入棧到出棧的過程。此區域也是線程私有的內存，可能拋出兩種異常：如果線程請求的棧深度大於虛擬機允許的深度將拋出StackOverflowError；如果虛擬機棧可以動態的擴展，擴展到無法動態的申請到足夠的內存時會拋出OOM異常。
3、本地方法棧(Native Method Stacks)
本地方法棧與虛擬機棧發揮的作用非常相似，區別就是虛擬機棧為虛擬機執行Java方法，本地方法棧則是為虛擬機使用到的Native方法服務。
4、堆區(Heap)
所有對象實例和數組都在堆區上分配，堆區是GC主要管理的區域。堆區還可以細分為新生代、老年代，新生代還分為一個Eden區和兩個Survivor區。此塊內存為所有線程共享區域，當堆中沒有足夠內存完成實例分配時會拋出OOM異常。
5、方法區(Method Area)
方法區也是所有線程共享區，用於存儲已被虛擬機載入的類信息、常量、靜態變數、即時編譯後的代碼等數據。GC在這個區域很少出現，這個區域內存回收的目標主要是對常量池的回收和類型的卸載，回收的內存比較少，所以也有稱這個區域為永久代(Permanent Generation)的。當方法區無法滿足內存分配時拋出OOM異常。
6、運行時常量池(Runtime Constant Pool)
運行時常量池是方法區的一部分，用於存放編譯期生成的各種字面量和符號引用。

垃圾收集(Garbage Collection)並不是Java獨有的，最早是出現在Lisp語言中，它做的事就是自動管理內存，也就是下面三個問題：
1、什麼時候回收
2、哪些內存需要回收
3、如何回收

1、什麼時候回收？
上面說到GC經常發生的區域是堆區，堆區還可以細分為新生代、老年代，新生代還分為一個Eden區和兩個Survivor區。
1.1 對象優先在Eden中分配，當Eden中沒有足夠空間時，虛擬機將發生一次Minor GC，因為Java大多數對象都是朝生夕滅，所以Minor GC非常頻繁，而且速度也很快；
1.2 Full GC，發生在老年代的GC，當老年代沒有足夠的空間時即發生Full GC，發生Full GC一般都會有一次Minor GC。大對象直接進入老年代，如很長的字元串數組，虛擬機提供一個-XX:PretenureSizeThreadhold參數，令大於這個參數值的對象直接在老年代中分配，避免在Eden區和兩個Survivor區發生大量的內存拷貝；
1.3 發生Minor GC時，虛擬機會檢測之前每次晉升到老年代的平均大小是否大於老年代的剩餘空間大小，如果大於，則進行一次Full GC，如果小於，則查看HandlePromotionFailure設置是否允許擔保失敗，如果允許，那隻會進行一次Minor GC，如果不允許，則改為進行一次Full GC。

2、哪些內存需要回收
jvm對不可用的對象進行回收，哪些對象是可用的，哪些是不可用的？Java並不是採用引用計數演算法來判定對象是否可用，而是採用根搜索演算法(GC Root Tracing)，當一個對象到GC Roots沒有任何引用相連接，用圖論的來說就是從GC Roots到這個對象不可達，則證明此對象是不可用的，說明此對象可以被GC。對於這些不可達對象，也不是一下子就被GC，而是至少要經歷兩次標記過程：如果對象在進行根搜索演算法後發現沒有與GC Roots相連接的引用鏈，那它將會第一次標記並且進行一次篩選，篩選條件是此對象有沒有必要執行finalize()方法，當對象沒有覆蓋finalize()方法或者finalize()方法已經被虛擬機調用執行過一次，這兩種情況都被視為沒有必要執行finalize()方法，對於沒有必要執行finalize()方法的將會被GC，對於有必要有必要執行的，對象在finalize()方法中可能會自救，也就是重新與引用鏈上的任何一個對象建立關聯即可。

3、如何回收
選擇不同的垃圾收集器，所使用的收集演算法也不同。
在新生代中，每次垃圾收集都發現有大批對象死去，只有少量存活，則使用復制演算法，新生代內存被分為一個較大的Eden區和兩個較小的Survivor區，每次只使用Eden區和一個Survivor區，當回收時將Eden區和Survivor還存活著的對象一次性的拷貝到另一個Survivor區上，最後清理掉Eden區和剛才使用過的Survivor區，Eden和Survivor的默認比例是8：1，可以使用-XX:SurvivorRatio來設置該比例。
而老年代中對象存活率高，沒有額外的空間對它進行分配擔保，必須使用「標記-清理」或「標記-整理」演算法。

C. majorgc觸發條件

Major GC通常是跟full GC是等價的，收集整個GC堆。但因為HotSpot VM發展了這么多年，外界對各種名詞的解讀已經完全混亂了，當有人說「major GC」的時候一定要問清楚他想要指的是上面的full GC還是old gen。

最簡單的分代式GC策略，按HotSpot VM的serial GC的實現來看，觸發條件是：
young GC：當young gen中的eden區分配滿的時候觸發。注意young GC中有部分存活對象會晉升到old gen，所以young GC後old gen的佔用量通常會有所升高。
full GC：當准備要觸發一次young GC時，如果發現統計數據說之前young GC的平均晉升大小比目前old gen剩餘的空間大，則不會觸發young GC而是轉為觸發full GC（因為HotSpot VM的GC里，除了CMS的concurrent collection之外，其它能收集old gen的GC都會同時收集整個GC堆，包括young gen，所以不需要事先觸發一次單獨的young GC）；或者，如果有perm gen的話，要在perm gen分配空間但已經沒有足夠空間時，也要觸發一次full GC；或者System.gc()、heap mp帶GC，默認也是觸發full GC。
HotSpot VM里其它非並發GC的觸發條件復雜一些，不過大致的原理與上面說的其實一樣。
當然也總有例外。Parallel Scavenge（-XX:+UseParallelGC）框架下，默認是在要觸發full GC前先執行一次young GC，並且兩次GC之間能讓應用程序稍微運行一小下，以期降低full GC的暫停時間（因為young GC會盡量清理了young gen的死對象，減少了full GC的工作量）。這是HotSpot VM里的奇葩嗯。

並發GC的觸發條件就不太一樣。以CMS GC為例，它主要是定時去檢查old gen的使用量，當使用量超過了觸發比例就會啟動一次CMS GC，對old gen做並發收集。