jvm垃圾收集回收
今天學習了jvm垃圾收集回收，現在終結一下學習的筆記，權當複習和以後的複習。
1.那麼首先我們來看看jvm預設情況下的記憶體分配和回收
大多數情況下，物件在新生代中 Eden 區分配。當 Eden 區沒有足夠空間進行分配時，虛擬機器將發起一次Minor GC。然後會把倖存的物件存進幸存區的From區 ，當From區也滿了了，虛擬機器將再發起一次Minor GC，把繼續存在物件存放在倖存區的To區，（這時候From區和To回倒過來，Form區變成To區，To區變成From區）當To區也滿了，虛擬機器將再發起一次Minor GC（輪詢15次預設情況下），就會進去老年區，當老年區也滿了，虛擬機器將再發起一次Full GC
我們來進行實際測試一下。
在測試之前我們先來看看 Minor Gc和Full GC 有什麼不同呢？
- 新生代GC（Minor GC）:指發生新生代的的垃圾收集動作，Minor GC非常頻繁，回收速度一般也比較快。
- 老年代GC（Major GC/Full GC）:指發生在老年代的GC，出現了Major GC經常會伴隨至少一次的Minor GC（並非絕對），Major GC的速度一般會比Minor GC的慢10倍以上。
那我麼先通過配置jvm的引數（新增的引數： -XX:+PrintGCDetails）列印gc看看對記憶體預設情況下的分配情況。
執行的結果：
我們來分析一下每行的結果：（預設情況下jvm會根據你機器的記憶體開闢開闢記憶體的）
def new generation total 4928K, used 3311K [0x04a00000, 0x04f50000, 0x09f50000)：
DefNewGeneration是一個young generation，包含了eden、from and to記憶體區，當虛擬機器啟動引數中沒有指定垃圾回收演算法時，預設使用該方式實現新生代。
eden space 4416K, 74% used [0x04a00000, 0x04d3bd10, 0x04e50000)：
表示新生區中的伊甸區的記憶體是4416k，已經使用了74%，細心的已經發現了，allocation1 = new byte[2000 * 1024];明明就是2M左右的大小，那麼為什麼對於4416k的伊甸區已經使用了74%呢，其實是這樣子的
from space 512K, 0% used [0x04e50000, 0x04e50000, 0x04ed0000)：
表示新生區的倖存區的From區分配的記憶體大小事512K，還沒有被使用
to space 512K, 0% used [0x04ed0000, 0x04ed0000, 0x04f50000)：
表示新生區的倖存區的To區分配的記憶體大小事512K，還沒有被使用
tenured generation total 10944K, used 0K [0x09f50000, 0x0aa00000, 0x14a00000)
the space 10944K, 0% used [0x09f50000, 0x09f50000, 0x09f50200, 0x0aa00000)：
表示老年區的記憶體大小事10944K，還沒有被使用。
Metaspace used 210K, capacity 2280K, committed 2368K, reserved 4480K：表示元數空間（不屬於堆的）
假如我們再為allocation2分配記憶體會出現什麼情況呢？allocation2 = new byte[1000*1024];
簡單解釋一下為什麼會出現這種情況： 因為給allocation2分配記憶體的時候eden區記憶體幾乎已經被分配完了，我們剛剛講了當Eden區沒有足夠空間進行分配時，虛擬機器將發起一次Minor GC.GC期間虛擬機器又發現allocation1無法存入Survior空間，所以只好通過 分配擔保機制 把新生代的物件提前轉移到老年代中去，老年代上的空間足夠存放allocation1，所以不會出現Full GC。執行Minor GC後，後面分配的物件如果能夠存在eden區的話，還是會在eden區分配記憶體。
1.2 大物件直接進入老年代
大物件就是需要大量連續記憶體空間的物件（比如：字串、陣列）。
為什麼要這樣呢？
為了避免為大物件分配記憶體時由於分配擔保機制帶來的複製而降低效率。
1.3 長期存活的物件將進入老年代
既然虛擬機器採用了分代收集的思想來管理記憶體，那麼記憶體回收時就必須能識別那些物件應放在新生代，那些物件應放在老年代中。為了做到這一點，虛擬機器給每個物件一個物件年齡（Age）計數器。
如果物件在 Eden 出生並經過第一次 Minor GC 後仍然能夠存活，並且能被 Survivor 容納的話，將被移動到 Survivor 空間中，並將物件年齡設為1.物件在 Survivor 中每熬過一次 MinorGC,年齡就增加1歲，當它的年齡增加到一定程度（預設為15歲），就會被晉升到老年代中。物件晉升到老年代的年齡閾值，可以通過引數 -XX:MaxTenuringThreshold 來設定。
2.如何判斷物件可以被回收
堆中幾乎放著所有的物件例項，對堆垃圾回收前的第一步就是要判斷那些物件已經死亡（即不能再被任何途徑使用的物件）。
給物件中新增一個引用計數器，每當有一個地方引用它，計數器就加1；當引用失效，計數器就減1；任何時候計數器為0的物件就是不可能再被使用的。
這個方法實現簡單，效率高，但是目前主流的虛擬機器中並沒有選擇這個演算法來管理記憶體，其最主要的原因是它很難解決物件之間相互迴圈引用的問題。 所謂物件之間的相互引用問題，如下面程式碼所示：除了物件objA 和 objB 相互引用著對方之外，這兩個物件之間再無任何引用。但是他們因為互相引用對方，導致它們的引用計數器都不為0，於是引用計數演算法無法通知 GC 回收器回收他們。
我們用一個例子結合圖例說明，如有以下的程式的。
當執行完第九行的時候簡略結構圖如下：
這個時候ReferenceCountingGcA和ReferenceCountingGcB的計數器都是2，當執行objA = null; objB = null;只不過是把objA和objB兩個兩線去了，但他們的計數器還是1，gc並不會去回收ReferenceCountingGcA和ReferenceCountingGcB，如果有大量這樣子引用存在肯定最後會導致記憶體溢位的。
2.2 可達性分析演算法
這個演算法的基本思想就是通過一系列的稱為 “GC Roots” 的物件作為起點，從這些節點開始向下搜尋，節點所走過的路徑稱為引用鏈，當一個物件到 GC Roots 沒有任何引用鏈相連的話，則證明此物件是不可用的。
GC Roots根節點：類載入器、Thread、虛擬機器棧的本地變量表、static成員、常量引用、本地方法棧的變數等等
2.3 finalize()方法最終判定物件是否存活
即使在可達性分析演算法中不可達的物件，也並非是“非死不可”的，這時候它們暫時處於“緩刑”階段，要真正宣告一個物件死亡，至少要經歷再次標記過程。
標記的前提是物件在進行可達性分析後發現沒有與GC Roots相連線的引用鏈。
當物件沒有覆蓋finalize方法，或者finzlize方法已經被虛擬機器呼叫過，虛擬機器將這兩種情況都視為“沒有必要執行”，物件被回收。
如果這個物件被判定為有必要執行finalize（）方法，那麼這個物件將會被放置在一個名為：F-Queue的佇列之中，並在稍後由一條虛擬機器自動建立的、低優先順序的Finalizer執行緒去執行。這裡所謂的“執行”是指虛擬機器會觸發這個方法，但並不承諾會等待它執行結束。這樣做的原因是，如果一個物件finalize（）方法中執行緩慢，或者發生死迴圈（更極端的情況），將很可能會導致F-Queue佇列中的其他物件永久處於等待狀態，甚至導致整個記憶體回收系統崩潰。
finalize（）方法是物件脫逃死亡命運的最後一次機會，稍後GC將對F-Queue中的物件進行第二次小規模標記，如果物件要在finalize（）中成功拯救自己----只要重新與引用鏈上的任何的一個物件建立關聯即可，譬如把自己賦值給某個類變數或物件的成員變數，那在第二次標記時它將移除出“即將回收”的集合。如果物件這時候還沒逃脫，那基本上它就真的被回收了。
如舉個例子：
如果沒有實施自救：肯定被gc回收匿名物件的
2.4 如何判斷一個常量是廢棄常量
執行時常量池主要回收的是廢棄的常量。那麼，我們如何判斷一個常量是廢棄常量呢？
假如在常量池中存在字串 "abc"，如果當前沒有任何String物件引用該字串常量的話，就說明常量 "abc" 就是廢棄常量，如果這時發生記憶體回收的話而且有必要的話，"abc" 就會被系統清理出常量池。
方法區主要回收的是無用的類，那麼如何判斷一個類是無用的類的呢？
判定一個常量是否是“廢棄常量”比較簡單，而要判定一個類是否是“無用的類”的條件則相對苛刻許多。類需要同時滿足下面3個條件才能算是 “無用的類” ：
- 該類所有的例項都已經被回收，也就是 Java 堆中不存在該類的任何例項。
- 載入該類的 ClassLoader 已經被回收。
- 該類對應的 java.lang.Class 物件沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。
虛擬機器可以對滿足上述3個條件的無用類進行回收，這裡說的僅僅是“可以”，而並不是和物件一樣不使用了就會必然被回收。
3.垃圾收集演算法
3.1 標記-清除演算法
演算法分為“標記”和“清除”階段：首先標記出所有需要回收的物件，在標記完成後統一回收所有被標記的物件。它是最基礎的收集演算法，效率也很高，但是會帶來兩個明顯的問題：
3.2 複製演算法
為了解決效率問題，“複製”收集演算法出現了。它可以將記憶體分為大小相同的兩塊，每次使用其中的一塊。當這一塊的記憶體使用完後，就將還存活的物件複製到另一塊去，然後再把使用的空間一次清理掉。這樣就使每次的記憶體回收都是對記憶體區間的一半進行回收。
3.3 標記-整理演算法
根據老年代的特點特出的一種標記演算法，標記過程仍然與“標記-清除”演算法一樣，但後續步驟不是直接對可回收物件回收，而是讓所有存活的物件向一段移動，然後直接清理掉端邊界以外的記憶體。
3.4 分代收集演算法
當前虛擬機器的垃圾收集都採用分代收集演算法，這種演算法沒有什麼新的思想，只是根據物件存活週期的不同將記憶體分為幾塊。一般將java堆分為新生代和老年代，這樣我們就可以根據各個年代的特點選擇合適的垃圾收集演算法。
比如在新生代中，每次收集都會有大量物件死去，所以可以選擇複製演算法，只需要付出少量物件的複製成本就可以完成每次垃圾收集。而老年代的物件存活機率是比較高的，而且沒有額外的空間對它進行分配擔保，所以我們必須選擇“標記-清除”或“標記-整理”演算法進行垃圾收集。
4.垃圾收集器
如果說收集演算法是記憶體回收的方法論，那麼垃圾收集器就是記憶體回收的具體實現。
雖然我們對各個收集器進行比較，但並非為了挑選出一個最好的收集器。因為直到現在為止還沒有最好的垃圾收集器出現，更加沒有萬能的垃圾收集器，我們能做的就是根據具體應用場景選擇適合自己的垃圾收集器。
4.1 Serial收集器
Serial（序列）收集器收集器是最基本、歷史最悠久的垃圾收集器了。大家看名字就知道這個收集器是一個單執行緒收集器了。它的 “單執行緒” 的意義不僅僅意味著它只會使用一條垃圾收集執行緒去完成垃圾收集工作，更重要的是它在進行垃圾收集工作的時候必須暫停其他所有的工作執行緒（ "Stop The World" ），直到它收集結束。
新生代採用複製演算法，老年代採用標記-整理演算法。(分代收集演算法)
虛擬機器的設計者們當然知道Stop The World帶來的不良使用者體驗，所以在後續的垃圾收集器設計中停頓時間在不斷縮短（仍然還有停頓，尋找最優秀的垃圾收集器的過程仍然在繼續）。
但是Serial收集器有沒有優於其他垃圾收集器的地方呢？當然有，它簡單而高效（與其他收集器的單執行緒相比）。Serial收集器由於沒有執行緒互動的開銷，自然可以獲得很高的單執行緒收集效率。
4.2 ParNew收集器
ParNew收集器其實就是Serial收集器的多執行緒版本，除了使用多執行緒進行垃圾收集外，其餘行為（控制引數、收集演算法、回收策略等等）和Serial收集器完全一樣。
它是許多執行在Server模式下的虛擬機器的首要選擇，除了Serial收集器外，只有它能與CMS收集器（真正意義上的併發收集器，後面會介紹到）配合工作。
並行和併發概念補充：
- 並行（Parallel） ：指多條垃圾收集執行緒並行工作，但此時使用者執行緒仍然處於等待狀態。適合科學計算、後臺處理等弱互動場景。
- 併發（Concurrent）：指使用者執行緒與垃圾收集執行緒同時執行（但不一定是並行，可能會交替執行），使用者程式在繼續執行，而垃圾收集器執行在另一個CPU上。適合Web應用。
Parallel Scavenge 收集器類似於ParNew 收集器，是Server 模式（記憶體大於2G，2個cpu）下的預設收集器，那麼它有什麼特別之處呢？
Parallel Scavenge收集器關注點是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的關注點更多的是使用者執行緒的停頓時間（提高使用者體驗）。所謂吞吐量就是CPU中用於執行使用者程式碼的時間與CPU總消耗時間的比值。 Parallel Scavenge收集器提供了很多引數供使用者找到最合適的停頓時間或最大吞吐量，如果對於收集器運作不太瞭解的話，可以選擇把記憶體管理優化交給虛擬機器去完成也是一個不錯的選擇。
4.4.Serial Old收集器
Serial收集器的老年代版本，它同樣是一個單執行緒收集器。它主要有兩大用途：一種用途是在JDK1.5以及以前的版本中與Parallel Scavenge收集器搭配使用，另一種用途是作為CMS收集器的後備方案。
Parallel Scavenge收集器的老年代版本。使用多執行緒和“標記-整理”演算法。在注重吞吐量以及CPU資源的場合，都可以優先考慮 Parallel Scavenge收集器和Parallel Old收集器。
4.6 CMS收集器(-XX:+UseConcMarkSweepGC(主要是old區使用))
CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標的收集器。它而非常符合在注重使用者體驗的應用上使用，它是HotSpot虛擬機器第一款真正意義上的併發收集器，它第一次實現了讓垃圾收集執行緒與使用者執行緒（基本上）同時工作。
從名字中的Mark Sweep這兩個詞可以看出，CMS收集器是一種 “標記-清除”演算法實現的，它的運作過程相比於前面幾種垃圾收集器來說更加複雜一些。整個過程分為四個步驟：
- 初始標記： 暫停所有的其他執行緒(STW)，並記錄下直接與root相連的物件，速度很快 ；
- 併發標記： 同時開啟GC和使用者執行緒，用一個閉包結構去記錄可達物件。但在這個階段結束，這個閉包結構並不能保證包含當前所有的可達物件。因為使用者執行緒可能會不斷的更新引用域，所以GC執行緒無法保證可達性分析的實時性。所以這個演算法裡會跟蹤記錄這些發生引用更新的地方。
- 重新標記： 重新標記階段就是為了修正併發標記期間因為使用者程式繼續執行而導致標記產生變動的那一部分物件的標記記錄，這個階段的停頓時間一般會比初始標記階段的時間稍長，遠遠比並發標記階段時間短
- 併發清除： 開啟使用者執行緒，同時GC執行緒開始對未標記的區域做清掃。
從它的名字就可以看出它是一款優秀的垃圾收集器，主要優點：併發收集、低停頓。但是它有下面三個明顯的缺點：
- 對CPU資源敏感（會和服務搶資源）；
- 無法處理浮動垃圾(在java業務程式執行緒與垃圾收集執行緒併發執行過程中又產生的垃圾，這種浮動垃圾只能等到下一次gc再清理了)；
- 它使用的回收演算法-“標記-清除”演算法會導致收集結束時會有大量空間碎片產生。
4.7 G1收集器(-XX:+UseG1GC)
G1 (Garbage-First)是一款面向伺服器的垃圾收集器,主要針對配備多顆處理器及大容量記憶體的機器. 以極高概率滿足GC停頓時間要求的同時,還具備高吞吐量效能特徵.
G1將Java堆劃分為多個大小相等的獨立區域（Region），雖保留新生代和老年代的概念，但不再是物理隔閡了，它們都是（可以不連續）Region的集合。
分配大物件（直接進Humongous區，專門存放短期巨型物件，不用直接進老年代，避免Full GC的大量開銷）不會因為無法找到連續空間而提前觸發下一次GC。
被視為JDK1.7中HotSpot虛擬機器的一個重要進化特徵。它具備以下特點：
- 並行與併發：G1能充分利用CPU、多核環境下的硬體優勢，使用多個CPU（CPU或者CPU核心）來縮短Stop-The-World停頓時間。部分其他收集器原本需要停頓Java執行緒來執行GC動作，G1收集器仍然可以通過併發的方式讓java程式繼續執行。
- 分代收集：雖然G1可以不需要其他收集器配合就能獨立管理整個GC堆，但是還是保留了分代的概念。
- 空間整合：與CMS的“標記--清理”演算法不同，G1從整體來看是基於“標記整理”演算法實現的收集器；從區域性上來看是基於“複製”演算法實現的。
- 可預測的停頓：這是G1相對於CMS的另一個大優勢，降低停頓時間是G1 和 CMS 共同的關注點，但G1 除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明確指定在一個長度為M毫秒的時間片段內完成垃圾收集。
- 初始標記（initial mark，STW）：在此階段，G1 GC 對根進行標記。該階段與常規的 (STW) 年輕代垃圾回收密切相關。
- 併發標記（Concurrent Marking）：G1 GC 在整個堆中查詢可訪問的（存活的）物件。
- 最終標記（Remark，STW）：該階段是 STW 回收，幫助完成標記週期。
- 篩選回收（Cleanup，STW）：篩選回收階段首先對各個Region的回收價值和成本進行排序，根據使用者所期望的GC停頓時間來制定回收計劃，這個階段其實也可以做到與使用者程式一起併發執行，但是因為只回收一部分Region，時間是使用者可控制的，而且停頓使用者執行緒將大幅提高收集效率。
G1收集器在後臺維護了一個優先列表，每次根據允許的收集時間，優先選擇回收價值最大的Region(這也就是它的名字Garbage-First的由來)。這種使用Region劃分記憶體空間以及有優先順序的區域回收方式，保證了GF收集器在有限時間內可以儘可能高的收集效率。
5. 如何選擇垃圾收集器
1. 優先調整堆的大小讓伺服器自己來選擇
2. 如果記憶體小於100M，使用序列收集器
3. 如果是單核，並且沒有停頓時間的要求，序列或JVM自己選擇
4. 如果允許停頓時間超過1秒，選擇並行或者JVM自己選
5. 如果響應時間最重要，並且不能超過1秒，使用併發收集器
下圖有連線的可以搭配使用，官方推薦使用G1，因為效能高
