概述

G1垃圾回收器是在Java7 update 4之后引入的一個新的垃圾回收器。G1是一個分代的，增量的，并行與并發的標記-復制垃圾回收器。它的設計目標是為了適應現在不斷擴大的內存和不斷增加的處理器數量，進一步降低暫停時間（pause time），同時兼顧良好的吞吐量。G1回收器和CMS比起來，有以下不同

• G1垃圾回收器是compacting（壓實）的，因此其回收得到的空間是連續的。這避免了CMS回收器因為不連續空間所造成的問題。如需要更大的堆空間，更多的floating garbage。連續空間意味著G1垃圾回收器可以不必采用空閑鏈表的內存分配方式，而可以直接采用bump-the-pointer的方式；
• G1回收器的內存與CMS回收器要求的內存模型有極大的不同。G1將內存劃分一個個固定大小的region，每個region可以是年輕代、老年代的一個。內存的回收是以region作為基本單位的；
• G1還有一個及其重要的特性：軟實時（soft real-time）。所謂的實時垃圾回收，是指在要求的時間內完成垃圾回收。“軟實時”則是指，用戶可以指定垃圾回收時間的限時，G1會努力在這個時限內完成垃圾回收，但是G1并不擔保每次都能在這個時限內完成垃圾回收。通過設定一個合理的目標，可以讓達到90%以上的垃圾回收時間都在這個時限內

G1的內存模型

分區概念

G1分區示意圖

• 分區Region

G1采用了分區(Region)的思路，將整個堆空間分成若干個大小相等的內存區域，每次分配對象空間將逐段地使用內存。因此，在堆的使用上，G1并不要求對象的存儲一定是物理上連續的，只要邏輯上連續即可；每個分區也不會確定地為某個代服務，可以按需在年輕代和老年代之間切換。啟動時可以通過參數-XX:G1HeapRegionSize=n可指定分區大小(1MB~32MB，且必須是2的冪)，默認將整堆劃分為2048個分區

• 卡片Card

在每個分區內部又被分成了若干個大小為512 Byte卡片(Card)，標識堆內存最小可用粒度所有分區的卡片將會記錄在全局卡片表(Global Card Table)中，分配的對象會占用物理上連續的若干個卡片，當查找對分區內對象的引用時便可通過記錄卡片來查找該引用對象（見RSet）。每次對內存的回收，都是對指定分區的卡片進行處理

• 堆Heap

G1同樣可以通過-Xms/-Xmx來指定堆空間大小。當發生年輕代收集或混合收集時，通過計算GC與應用的耗費時間比，自動調整堆空間大小。如果GC頻率太高，則通過增加堆尺寸，來減少GC頻率，相應地GC占用的時間也隨之降低；目標參數-XX:GCTimeRatio即為GC與應用的耗費時間比，G1默認為9，而CMS默認為99，因為CMS的設計原則是耗費在GC上的時間盡可能的少。另外，當空間不足，如對象空間分配或轉移失敗時，G1會首先嘗試增加堆空間，如果擴容失敗，則發起擔保的Full GC。Full GC后，堆尺寸計算結果也會調整堆空間

分代模型

• ?分代垃圾收集

分代垃圾收集可以將關注點集中在最近被分配的對象上，而無需整堆掃描，避免長命對象的拷貝，同時獨立收集有助于降低響應時間。雖然分區使得內存分配不再要求緊湊的內存空間，但G1依然使用了分代的思想。與其他垃圾收集器類似，G1將內存在邏輯上劃分為年輕代和老年代，其中年輕代又劃分為Eden空間和Survivor空間。但年輕代空間并不是固定不變的，當現有年輕代分區占滿時，JVM會分配新的空閑分區加入到年輕代空間

整個年輕代內存會在初始空間-XX:G1NewSizePercent(默認整堆5%)與最大空間(默認60%)之間動態變化，且由參數目標暫停時間-XX:MaxGCPauseMillis(默認200ms)、需要擴縮容的大小以-XX:G1MaxNewSizePercent及分區的已記憶集合(RSet)計算得到。當然，G1依然可以設置固定的年輕代大小(參數-XX:NewRatio、-Xmn)，但同時暫停目標將失去意義

• 本地分配緩沖 Local allocation buffer (Lab)

值得注意的是，由于分區的思想，每個線程均可以"認領"某個分區用于線程本地的內存分配，而不需要顧及分區是否連續。因此，每個應用線程和GC線程都會獨立的使用分區，進而減少同步時間，提升GC效率，這個分區稱為本地分配緩沖區(Lab)

其中，應用線程可以獨占一個本地緩沖區(TLAB)來創建的對象，而大部分都會落入Eden區域(巨型對象或分配失敗除外)，因此TLAB的分區屬于Eden空間；而每次垃圾收集時，每個GC線程同樣可以獨占一個本地緩沖區(GCLAB)用來轉移對象，每次回收會將對象復制到Suvivor空間或老年代空間；對于從Eden/Survivor空間晉升(Promotion)到Survivor/老年代空間的對象，同樣有GC獨占的本地緩沖區進行操作，該部分稱為晉升本地緩沖區(PLAB)

分區模型

G1對內存的使用以分區(Region)為單位，而對對象的分配則以卡片(Card)為單位

• 巨形對象Humongous Region

一個大小達到甚至超過分區大小一半的對象稱為巨型對象(Humongous Object)。當線程為巨型分配空間時，不能簡單在TLAB進行分配，因為巨型對象的移動成本很高，而且有可能一個分區不能容納巨型對象。因此，巨型對象會直接在老年代分配，所占用的連續空間稱為巨型分區(Humongous Region)。G1內部做了一個優化，一旦發現沒有引用指向巨型對象，則可直接在年輕代收集周期中被回收

巨型對象會獨占一個、或多個連續分區，其中第一個分區被標記為開始巨型(StartsHumongous)，相鄰連續分區被標記為連續巨型(ContinuesHumongous)。由于無法享受Lab帶來的優化，并且確定一片連續的內存空間需要掃描整堆，因此確定巨型對象開始位置的成本非常高，如果可以，應用程序應避免生成巨型對象

• 已記憶集合Remember Set (RSet)

在串行和并行收集器中，GC通過整堆掃描，來確定對象是否處于可達路徑中。然而G1為了避免STW式的整堆掃描，在每個分區記錄了一個已記憶集合(RSet)，內部類似一個反向指針，記錄引用分區內對象的卡片索引。當要回收該分區時，通過掃描分區的RSet，來確定引用本分區內的對象是否存活，進而確定本分區內的對象存活情況

事實上，并非所有的引用都需要記錄在RSet中，如果一個分區確定需要掃描，那么無需RSet也可以無遺漏的得到引用關系。那么引用源自本分區的對象，當然不用落入RSet中；同時，G1 GC每次都會對年輕代進行整體收集，因此引用源自年輕代的對象，也不需要在RSet中記錄。最后只有老年代的分區可能會有RSet記錄，這些分區稱為擁有RSet分區(an RSet’s owning region)

• Per Region Table (PRT)

RSet在內部使用Per Region Table(PRT)記錄分區的引用情況。由于RSet的記錄要占用分區的空間，如果一個分區非常"受歡迎"，那么RSet占用的空間會上升，從而降低分區的可用空間。G1應對這個問題采用了改變RSet的密度的方式，在PRT中將會以三種模式記錄引用

• 稀少：直接記錄引用對象的卡片索引
• 細粒度：記錄引用對象的分區索引
• 粗粒度：只記錄引用情況，每個分區對應一個比特位

粗粒度的PRT只是記錄了引用數量，需要通過整堆掃描才能找出所有引用，因此掃描速度也是最慢的

收集集合 (CSet)

CSet收集示意圖

收集集合(CSet)代表每次GC暫停時回收的一系列目標分區。在任意一次收集暫停中，CSet所有分區都會被釋放，內部存活的對象都會被轉移到分配的空閑分區中。因此無論是年輕代收集，還是混合收集，工作的機制都是一致的。年輕代收集CSet只容納年輕代分區，而混合收集會通過啟發式算法，在老年代候選回收分區中，篩選出回收收益最高的分區添加到CSet中

候選老年代分區的CSet準入條件，可以通過活躍度閾值-XX:G1MixedGCLiveThresholdPercent(默認85%)進行設置，從而攔截那些回收開銷巨大的對象；同時，每次混合收集可以包含候選老年代分區，可根據CSet對堆的總大小占比-XX:G1OldCSetRegionThresholdPercent(默認10%)設置數量上限

G1的收集都是根據CSet進行操作的，年輕代收集與混合收集沒有明顯的不同，最大的區別在于兩種收集的觸發條件

• 年輕代收集集合 CSet of Young Collection

應用線程不斷活動后，年輕代空間會被逐漸填滿。當JVM分配對象到Eden區域失敗(Eden區已滿)時，便會觸發一次STW式的年輕代收集。在年輕代收集中，Eden分區存活的對象將被拷貝到Survivor分區；原有Survivor分區存活的對象，將根據任期閾值(tenuring threshold)分別晉升到PLAB中，新的survivor分區和老年代分區。而原有的年輕代分區將被整體回收掉

年輕代收集還負責維護對象的年齡(存活次數)，輔助判斷老化(tenuring)對象晉升的時候是到Survivor分區還是到老年代分區。年輕代收集首先先將晉升對象尺寸總和、對象年齡信息維護到年齡表中，再根據年齡表、Survivor尺寸、Survivor填充容量-XX:TargetSurvivorRatio(默認50%)、最大任期閾值-XX:MaxTenuringThreshold(默認15)，計算出一個恰當的任期閾值，凡是超過任期閾值的對象都會被晉升到老年代

• 混合收集集合 CSet of Mixed Collection

年輕代收集不斷活動后，老年代的空間也會被逐漸填充。當老年代占用空間超過整堆比IHOP閾值-XX:InitiatingHeapOccupancyPercent(默認45%)時，G1就會啟動一次混合垃圾收集周期。為了滿足暫停目標，G1可能不能一口氣將所有的候選分區收集掉，因此G1可能會產生連續多次的混合收集與應用線程交替執行，每次STW的混合收集與年輕代收集過程相類似

為了確定包含到年輕代收集集合CSet的老年代分區，JVM通過參數混合周期的最大總次數-XX:G1MixedGCCountTarget(默認8)、堆廢物百分比-XX:G1HeapWastePercent(默認5%)。通過候選老年代分區總數與混合周期最大總次數，確定每次包含到CSet的最小分區數量；根據堆廢物百分比，當收集達到參數時，不再啟動新的混合收集。而每次添加到CSet的分區，則通過計算得到的GC效率進行安排

• 并發標記算法（三色標記法）

CMS和G1在并發標記時使用的是同一個算法：三色標記法，使用白灰黑三種顏色標記對象。白色是未標記；灰色自身被標記，引用的對象未標記；黑色自身與引用對象都已標記

GC 開始前所有對象都是白色，GC 一開始所有根能夠直達的對象被壓到棧中，待搜索，此時顏色是灰色。然后灰色對象依次從棧中取出搜索子對象，子對象也會被涂為灰色，入棧。當其所有的子對象都涂為灰色之后該對象被涂為黑色。當 GC 結束之后灰色對象將全部沒了，剩下黑色的為存活對象，白色的為垃圾

• 漏標問題

在remark過程中，黑色指向了白色，如果不對黑色重新掃描，則會漏標。會把白色D對象當作沒有新引用指向從而回收掉

并發標記過程中，Mutator 刪除了所有從灰色到白色的引用，會產生漏標。此時白色對象應該被回收

產生漏標問題的條件有兩個

• 黑色對象指向了白色對象
• 灰色對象指向白色對象的引用消失

所以要解決漏標問題，打破兩個條件之一即可

• 跟蹤黑指向白的增加 incremental update：增量更新，關注引用的增加，把黑色重新標記為灰色，下次重新掃描屬性。CMS采用該方法。
• 記錄灰指向白的消失 SATB snapshot at the beginning：關注引用的刪除，當灰–>白消失時，要把這個 引用 推到GC的堆棧，保證白還能被GC掃描到。G1采用該方法

為什么G1采用SATB而不用 incremental update？

因為采用incremental update把黑色重新標記為灰色后，之前掃描過的還要再掃描一遍，效率太低。G1有RSet與SATB相配合。Card Table里記錄了RSet，RSet里記錄了其他對象指向自己的引用，這樣就不需要再掃描其他區域，只要掃描RSet就可以了

也就是說，灰色–>白色 引用消失時，如果沒有 黑色–>白色，引用會被push到堆棧，下次掃描時拿到這個引用，由于有RSet的存在，不需要掃描整個堆去查找指向白色的引用，效率比較高。SATB配合RSet渾然天成

G1的活動周期

G1垃圾收集活動匯總

G1垃圾收集活動周期圖

RSet的維護

由于不能整堆掃描，又需要計算分區確切的活躍度，因此，G1需要一個增量式的完全標記并發算法，通過維護RSet，得到準確的分區引用信息。在G1中，RSet的維護主要來源兩個方面：寫柵欄(Write Barrier)和并發優化線程(Concurrence Refinement Threads)

• 柵欄Barrier

柵欄代碼示意

柵欄是指在原生代碼片段中，當某些語句被執行時，柵欄代碼也會被執行。而G1主要在賦值語句中，使用寫前柵欄(Pre-Write Barrrier)和寫后柵欄(Post-Write Barrrier)。事實上，寫柵欄的指令序列開銷非常昂貴，應用吞吐量也會根據柵欄復雜度而降低

寫前柵欄 Pre-Write Barrrier

即將執行一段賦值語句時，等式左側對象將修改引用到另一個對象，那么等式左側對象原先引用的對象所在分區將因此喪失一個引用，那么JVM就需要在賦值語句生效之前，記錄喪失引用的對象。JVM并不會立即維護RSet，而是通過批量處理，在將來RSet更新(見SATB)

寫后柵欄 Post-Write Barrrier

當執行一段賦值語句后，等式右側對象獲取了左側對象的引用，那么等式右側對象所在分區的RSet也應該得到更新。同樣為了降低開銷，寫后柵欄發生后，RSet也不會立即更新，同樣只是記錄此次更新日志，在將來批量處理(見Concurrence Refinement Threads)

• 起始快照算法Snapshot at the beginning (SATB)

Taiichi Tuasa貢獻的增量式完全并發標記算法起始快照算法(SATB)，主要針對標記-清除垃圾收集器的并發標記階段，非常適合G1的分區塊的堆結構，同時解決了CMS的主要煩惱：重新標記暫停時間長帶來的潛在風險

SATB會創建一個對象圖，相當于堆的邏輯快照，從而確保并發標記階段所有的垃圾對象都能通過快照被鑒別出來。當賦值語句發生時，應用將會改變了它的對象圖，那么JVM需要記錄被覆蓋的對象。因此寫前柵欄會在引用變更前，將值記錄在SATB日志或緩沖區中。每個線程都會獨占一個SATB緩沖區，初始有256條記錄空間。當空間用盡時，線程會分配新的SATB緩沖區繼續使用，而原有的緩沖去則加入全局列表中。最終在并發標記階段，并發標記線程(Concurrent Marking Threads)在標記的同時，還會定期檢查和處理全局緩沖區列表的記錄，然后根據標記位圖分片的標記位，掃描引用字段來更新RSet。此過程又稱為并發標記/SATB寫前柵欄

• 并發優化線程Concurrence Refinement Threads

G1中使用基于Urs H?lzle的快速寫柵欄，將柵欄開銷縮減到2個額外的指令。柵欄將會更新一個card table type的結構來跟蹤代間引用

當賦值語句發生后，寫后柵欄會先通過G1的過濾技術判斷是否是跨分區的引用更新，并將跨分區更新對象的卡片加入緩沖區序列，即更新日志緩沖區或臟卡片隊列。與SATB類似，一旦日志緩沖區用盡，則分配一個新的日志緩沖區，并將原來的緩沖區加入全局列表中

并發優化線程(Concurrence Refinement Threads)，只專注掃描日志緩沖區記錄的卡片來維護更新RSet，線程最大數目可通過-XX:G1ConcRefinementThreads(默認等于-XX:ParellelGCThreads)設置。并發優化線程永遠是活躍的，一旦發現全局列表有記錄存在，就開始并發處理。如果記錄增長很快或者來不及處理，那么通過閾值-X:G1ConcRefinementGreenZone/-XX:G1ConcRefinementYellowZone/-XX:G1ConcRefinementRedZone，G1會用分層的方式調度，使更多的線程處理全局列表。如果并發優化線程也不能跟上緩沖區數量，則Mutator線程(Java應用線程)會掛起應用并被加進來幫助處理，直到全部處理完。因此，必須避免此類場景出現

并發標記周期 Concurrent Marking Cycle

并發標記周期是G1中非常重要的階段，這個階段將會為混合收集周期識別垃圾最多的老年代分區。整個周期完成根標記、識別所有(可能)存活對象，并計算每個分區的活躍度，從而確定GC效率等級

當達到IHOP閾值-XX:InitiatingHeapOccupancyPercent(老年代占整堆比，默認45%)時，便會觸發并發標記周期。整個并發標記周期將由初始標記(Initial Mark)、根分區掃描(Root Region Scanning)、并發標記(Concurrent Marking)、重新標記(Remark)、清除(Cleanup)幾個階段組成。其中，初始標記(隨年輕代收集一起活動)、重新標記、清除是STW的，而并發標記如果來不及標記存活對象，則可能在并發標記過程中，G1又觸發了幾次年輕代收集

• 并發標記線程 Concurrent Marking Threads

并發標記位圖過程

要標記存活的對象，每個分區都需要創建位圖(Bitmap)信息來存儲標記數據，來確定標記周期內被分配的對象。G1采用了兩個位圖Previous Bitmap、Next Bitmap，來存儲標記數據，Previous位圖存儲上次的標記數據，Next位圖在標記周期內不斷變化更新，同時Previous位圖的標記數據也越來越過時，當標記周期結束后Next位圖便替換Previous位圖，成為上次標記的位圖。同時，每個分區通過頂部開始標記(TAMS)，來記錄已標記過的內存范圍。同樣的，G1使用了兩個頂部開始標記Previous TAMS(PTAMS)、Next TAMS(NTAMS)，記錄已標記的范圍

在并發標記階段，G1會根據參數-XX:ConcGCThreads(默認GC線程數的1/4，即-XX:ParallelGCThreads/4)，分配并發標記線程(Concurrent Marking Threads)，進行標記活動。每個并發線程一次只掃描一個分區，并通過"手指"指針的方式優化獲取分區。并發標記線程是爆發式的，在給定的時間段拼命干活，然后休息一段時間，再拼命干活

每個并發標記周期，在初始標記STW的最后，G1會分配一個空的Next位圖和一個指向分區頂部(Top)的NTAMS標記。Previous位圖記錄的上次標記數據，上次的標記位置，即PTAMS，在PTAMS與分區底部(Bottom)的范圍內，所有的存活對象都已被標記。那么，在PTAMS與Top之間的對象都將是隱式存活(Implicitly Live)對象。在并發標記階段，Next位圖吸收了Previous位圖的標記數據，同時每個分區都會有新的對象分配，則Top與NTAMS分離，前往更高的地址空間。在并發標記的一次標記中，并發標記線程將找出NTAMS與PTAMS之間的所有存活對象，將標記數據存儲在Next位圖中。同時，在NTAMS與Top之間的對象即成為已標記對象。如此不斷地更新Next位圖信息，并在清除階段與Previous位圖交換角色

• ?初始標記 Initial Mark

初始標記(Initial Mark)負責標記所有能被直接可達的根對象(原生棧對象、全局對象、JNI對象)，根是對象圖的起點，因此初始標記需要將Mutator線程(Java應用線程)暫停掉，也就是需要一個STW的時間段。事實上，當達到IHOP閾值時，G1并不會立即發起并發標記周期，而是等待下一次年輕代收集，利用年輕代收集的STW時間段，完成初始標記，這種方式稱為借道(Piggybacking)。在初始標記暫停中，分區的NTAMS都被設置到分區頂部Top，初始標記是并發執行，直到所有的分區處理完

• 根分區掃描 Root Region Scanning

在初始標記暫停結束后，年輕代收集也完成的對象復制到Survivor的工作，應用線程開始活躍起來。此時為了保證標記算法的正確性，所有新復制到Survivor分區的對象，都需要被掃描并標記成根，這個過程稱為根分區掃描(Root Region Scanning)，同時掃描的Suvivor分區也被稱為根分區(Root Region)。根分區掃描必須在下一次年輕代垃圾收集啟動前完成(并發標記的過程中，可能會被若干次年輕代垃圾收集打斷)，因為每次GC會產生新的存活對象集合

• 并發標記 Concurrent Marking

和應用線程并發執行，并發標記線程在并發標記階段啟動，由參數-XX:ConcGCThreads(默認GC線程數的1/4，即-XX:ParallelGCThreads/4)控制啟動數量，每個線程每次只掃描一個分區，從而標記出存活對象圖。在這一階段會處理Previous/Next標記位圖，掃描標記對象的引用字段。同時，并發標記線程還會定期檢查和處理STAB全局緩沖區列表的記錄，更新對象引用信息。參數-XX:+ClassUnloadingWithConcurrentMark會開啟一個優化，如果一個類不可達(不是對象不可達)，則在重新標記階段，這個類就會被直接卸載。所有的標記任務必須在堆滿前就完成掃描，如果并發標記耗時很長，那么有可能在并發標記過程中，又經歷了幾次年輕代收集。如果堆滿前沒有完成標記任務，則會觸發擔保機制，經歷一次長時間的串行Full GC

• 存活數據計算 Live Data Accounting

存活數據計算(Live Data Accounting)是標記操作的附加產物，只要一個對象被標記，同時會被計算字節數，并計入分區空間。只有NTAMS以下的對象會被標記和計算，在標記周期的最后，Next位圖將被清空，等待下次標記周期

• 重新標記 Remark

重新標記(Remark)是最后一個標記階段。在該階段中，G1需要一個暫停的時間，去處理剩下的SATB日志緩沖區和所有更新，找出所有未被訪問的存活對象，同時安全完成存活數據計算。這個階段也是并行執行的，通過參數-XX:ParallelGCThread可設置GC暫停時可用的GC線程數。同時，引用處理也是重新標記階段的一部分，所有重度使用引用對象(弱引用、軟引用、虛引用、最終引用)的應用都會在引用處理上產生開銷

• 清除 Cleanup

緊挨著重新標記階段的清除(Clean)階段也是STW的。Previous/Next標記位圖、以及PTAMS/NTAMS，都會在清除階段交換角色。清除階段主要執行以下操作

• RSet梳理，啟發式算法會根據活躍度和RSet尺寸對分區定義不同等級，同時RSet數理也有助于發現無用的引用。參數-XX:+PrintAdaptiveSizePolicy可以開啟打印啟發式算法決策細節；
• 整理堆分區，為混合收集周期識別回收收益高(基于釋放空間和暫停目標)的老年代分區集合；
• 識別所有空閑分區，即發現無存活對象的分區。該分區可在清除階段直接回收，無需等待下次收集周期

年輕代收集/混合收集周期

年輕代收集和混合收集周期，是G1回收空間的主要活動。當應用運行開始時，堆內存可用空間還比較大，只會在年輕代滿時，觸發年輕代收集；隨著老年代內存增長，當到達IHOP閾值-XX:InitiatingHeapOccupancyPercent(老年代占整堆比，默認45%)時，G1開始著手準備收集老年代空間。首先經歷并發標記周期，識別出高收益的老年代分區，前文已述。但隨后G1并不會馬上開始一次混合收集，而是讓應用線程先運行一段時間，等待觸發一次年輕代收集。在這次STW中，G1將保準整理混合收集周期。接著再次讓應用線程運行，當接下來的幾次年輕代收集時，將會有老年代分區加入到CSet中，即觸發混合收集，這些連續多次的混合收集稱為混合收集周期(Mixed Collection Cycle)

• GC工作線程數

JVM可以通過參數-XX:ParallelGCThreads進行指定GC工作的線程數量。參數-XX:ParallelGCThreads默認值并不是固定的，而是根據當前的CPU資源進行計算。如果用戶沒有指定，且CPU小于等于8，則默認與CPU核數相等；若CPU大于8，則默認JVM會經過計算得到一個小于CPU核數的線程數；當然也可以人工指定與CPU核數相等

• 年輕代收集 Young Collection

每次收集過程中，既有并行執行的活動，也有串行執行的活動，但都可以是多線程的。在并行執行的任務中，如果某個任務過重，會導致其他線程在等待某項任務的處理，需要對這些地方進行優化

并行活動

• 外部根分區掃描 Ext Root Scanning：此活動對堆外的根(JVM系統目錄、VM數據結構、JNI線程句柄、硬件寄存器、全局變量、線程對棧根)進行掃描，發現那些沒有加入到暫停收集集合CSet中的對象。如果系統目錄(單根)擁有大量加載的類，最終可能其他并行活動結束后，該活動依然沒有結束而帶來的等待時間
• 更新已記憶集合 Update RS：并發優化線程會對臟卡片的分區進行掃描更新日志緩沖區來更新RSet，但只會處理全局緩沖列表。作為補充，所有被記錄但是還沒有被優化線程處理的剩余緩沖區，會在該階段處理，變成已處理緩沖區(Processed Buffers)。為了限制花在更新RSet的時間，可以設置暫停占用百分比-XX:G1RSetUpdatingPauseTimePercent(默認10%，即-XX:MaxGCPauseMills/10)。值得注意的是，如果更新日志緩沖區更新的任務不降低，單純地減少RSet的更新時間，會導致暫停中被處理的緩沖區減少，將日志緩沖區更新工作推到并發優化線程上，從而增加對Java應用線程資源的爭奪
• RSet掃描 Scan RS：在收集當前CSet之前，考慮到分區外的引用，必須掃描CSet分區的RSet。如果RSet發生粗化，則會增加RSet的掃描時間。開啟診斷模式-XX:UnlockDiagnosticVMOptions后，通過參數-XX:+G1SummarizeRSetStats可以確定并發優化線程是否能夠及時處理更新日志緩沖區，并提供更多的信息，來幫助為RSet粗化總數提供窗口。參數-XX：G1SummarizeRSetStatsPeriod=n可設置RSet的統計周期，即經歷多少此GC后進行一次統計
• 代碼根掃描 Code Root Scanning：對代碼根集合進行掃描，掃描JVM編譯后代碼Native Method的引用信息(nmethod掃描)，進行RSet掃描。事實上，只有CSet分區中的RSet有強代碼根時，才會做nmethod掃描，查找對CSet的引用
• 轉移和回收 Object Copy：通過選定的CSet以及CSet分區完整的引用集，將執行暫停時間的主要部分：CSet分區存活對象的轉移、CSet分區空間的回收。通過工作竊取機制來負載均衡地選定復制對象的線程，并且復制和掃描對象被轉移的存活對象將拷貝到每個GC線程分配緩沖區GCLAB。G1會通過計算，預測分區復制所花費的時間，從而調整年輕代的尺寸
• 終止 Termination：完成上述任務后，如果任務隊列已空，則工作線程會發起終止要求。如果還有其他線程繼續工作，空閑的線程會通過工作竊取機制嘗試幫助其他線程處理。而單獨執行根分區掃描的線程，如果任務過重，最終會晚于終止
• GC外部的并行活動 GC Worker Other：該部分并非GC的活動，而是JVM的活動導致占用了GC暫停時間(例如JNI編譯)

串行活動

• 代碼根更新 Code Root Fixup：根據轉移對象更新代碼根
• 代碼根清理 Code Root Purge：清理代碼根集合表
• 清除全局卡片標記 Clear CT：在任意收集周期會掃描CSet與RSet記錄的PRT，掃描時會在全局卡片表中進行標記，防止重復掃描。在收集周期的最后將會清除全局卡片表中的已掃描標志
• 選擇下次收集集合 Choose CSet：該部分主要用于并發標記周期后的年輕代收集、以及混合收集中，在這些收集過程中，由于有老年代候選分區的加入，往往需要對下次收集的范圍做出界定；但單純的年輕代收集中，所有收集的分區都會被收集，不存在選擇
• 引用處理 Ref Proc：主要針對軟引用、弱引用、虛引用、final引用、JNI引用。當Ref Proc占用時間過多時，可選擇使用參數-XX:ParallelRefProcEnabled激活多線程引用處理。G1希望應用能小心使用軟引用，因為軟引用會一直占據內存空間直到空間耗盡時被Full GC回收掉；即使未發生Full GC，軟引用對內存的占用，也會導致GC次數的增加
• 引用排隊 Ref Enq：此項活動可能會導致RSet的更新，此時會通過記錄日志，將關聯的卡片標記為臟卡片
• 卡片重新臟化 Redirty Cards：重新臟化卡片
• 回收空閑巨型分區 Humongous Reclaim：G1做了一個優化：通過查看所有根對象以及年輕代分區的RSet，如果確定RSet中巨型對象沒有任何引用，則說明G1發現了一個不可達的巨型對象，該對象分區會被回收
• 釋放分區 Free CSet：回收CSet分區的所有空間，并加入到空閑分區中
• 其他活動 Other：GC中可能還會經歷其他耗時很小的活動，如修復JNI句柄等

并發標記周期后的年輕代收集 Young Collection Following Concurrent Marking Cycle

當G1發起并發標記周期之后，并不會馬上開始混合收集。G1會先等待下一次年輕代收集，然后在該收集階段中，確定下次混合收集的CSet(Choose CSet)

• 混合收集周期 Mixed Collection Cycle

單次的混合收集與年輕代收集并無二致。根據暫停目標，老年代的分區可能不能一次暫停收集中被處理完，G1會發起連續多次的混合收集，稱為混合收集周期(Mixed Collection Cycle)。G1會計算每次加入到CSet中的分區數量、混合收集進行次數，并且在上次的年輕代收集、以及接下來的混合收集中，G1會確定下次加入CSet的分區集(Choose CSet)，并且確定是否結束混合收集周期

• 轉移失敗的擔保機制 Full GC

轉移失敗(Evacuation Failure)是指當G1無法在堆空間中申請新的分區時，G1便會觸發擔保機制，執行一次STW式的、單線程的Full GC。Full GC會對整堆做標記清除和壓縮，最后將只包含純粹的存活對象。參數-XX:G1ReservePercent(默認10%)可以保留空間，來應對晉升模式下的異常情況，最大占用整堆50%，更大也無意義

G1在以下場景中會觸發Full GC，同時會在日志中記錄to-space-exhausted以及Evacuation Failure

• 從年輕代分區拷貝存活對象時，無法找到可用的空閑分區
• 從老年代分區轉移存活對象時，無法找到可用的空閑分區
• 分配巨型對象時在老年代無法找到足夠的連續分區

由于G1的應用場合往往堆內存都比較大，所以Full GC的收集代價非常昂貴，應該避免Full GC的發生

總結

G1是一款非常優秀的垃圾收集器，不僅適合堆內存大的應用，同時也簡化了調優的工作。通過主要的參數初始和最大堆空間、以及最大容忍的GC暫停目標，就能得到不錯的性能；同時，我們也看到G1對內存空間的浪費較高，但通過首先收集盡可能多的垃圾(Garbage First)的設計原則，可以及時發現過期對象，從而讓內存占用處于合理的水平。

雖然G1也有類似CMS的收集動作：初始標記、并發標記、重新標記、清除、轉移回收，并且也以一個串行收集器做擔保機制，但單純地以類似前三種的過程描述顯得并不是很妥當

• G1的設計原則是"首先收集盡可能多的垃圾(Garbage First)"。因此，G1并不會等內存耗盡(串行、并行)或者快耗盡(CMS)的時候開始垃圾收集，而是在內部采用了啟發式算法，在老年代找出具有高收集收益的分區進行收集。同時G1可以根據用戶設置的暫停時間目標自動調整年輕代和總堆大小，暫停目標越短年輕代空間越小、總空間就越大；
• G1采用內存分區(Region)的思路，將內存劃分為一個個相等大小的內存分區，回收時則以分區為單位進行回收，存活的對象復制到另一個空閑分區中。由于都是以相等大小的分區為單位進行操作，因此G1天然就是一種壓縮方案(局部壓縮)；
• G1雖然也是分代收集器，但整個內存分區不存在物理上的年輕代與老年代的區別，也不需要完全獨立的survivor(to space)堆做復制準備。G1只有邏輯上的分代概念，或者說每個分區都可能隨G1的運行在不同代之間前后切換；
• G1的收集都是STW的，但年輕代和老年代的收集界限比較模糊，采用了混合(mixed)收集的方式。即每次收集既可能只收集年輕代分區(年輕代收集)，也可能在收集年輕代的同時，包含部分老年代分區(混合收集)，這樣即使堆內存很大時，也可以限制收集范圍，從而降低停頓

總結

以上是生活随笔為你收集整理的Java 垃圾回收器G1介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。