轉(zhuǎn)載自?可能是最全面的 Java G1學(xué)習(xí)筆記

引子

最近遇到很多朋友過來咨詢G1調(diào)優(yōu)的問題，我自己去年有專門學(xué)過一次G1，但是當(dāng)時只是看了個皮毛，因此自己也有不少問題。總體來講，對于G1我有幾個疑惑，希望能夠在這篇文章中得到解決。

G1出現(xiàn)的初衷是什么？

G1適合在什么場景下使用？

G1的trade-off是什么？

G1的詳細(xì)過程？

如何理解G1的gc日志?

G1的調(diào)優(yōu)思路？

G1和CMS的對比和選擇？

一、基礎(chǔ)知識

1. 初衷

在G1提出之前，經(jīng)典的垃圾收集器主要有三種類型：串行收集器、并行收集器和并發(fā)標(biāo)記清除收集器，這三種收集器分別可以是滿足Java應(yīng)用三種不同的需求：內(nèi)存占用及并發(fā)開銷最小化、應(yīng)用吞吐量最大化和應(yīng)用GC暫停時間最小化，但是，上述三種垃圾收集器都有幾個共同的問題：（1）所有針對老年代的操作必須掃描整個老年代空間；（2）新生代和老年代是獨立的連續(xù)的內(nèi)存塊，必須先決定年輕代和老年代在虛擬地址空間的位置。

2. 設(shè)計目標(biāo)

G1是一種服務(wù)端應(yīng)用使用的垃圾收集器，目標(biāo)是用在多核、大內(nèi)存的機器上，它在大多數(shù)情況下可以實現(xiàn)指定的GC暫停時間，同時還能保持較高的吞吐量。

3. 使用場景

G1適用于以下幾種應(yīng)用：

• 可以像CMS收集器一樣，允許垃圾收集線程和應(yīng)用線程并行執(zhí)行，即需要額外的CPU資源；

• 壓縮空閑空間不會延長GC的暫停時間；

• 需要更易預(yù)測的GC暫停時間；

• 不需要實現(xiàn)很高的吞吐量

二、G1的重要概念

1. 分區(qū)（Region）

G1采取了不同的策略來解決并行、串行和CMS收集器的碎片、暫停時間不可控制等問題——G1將整個堆分成相同大小的分區(qū)（Region），如下圖所示。

?

G1的堆模型

每個分區(qū)都可能是年輕代也可能是老年代，但是在同一時刻只能屬于某個代。
年輕代、幸存區(qū)、老年代這些概念還存在，成為邏輯上的概念，這樣方便復(fù)用之前分代框架的邏輯。在物理上不需要連續(xù)，則帶來了額外的好處——有的分區(qū)內(nèi)垃圾對象特別多，有的分區(qū)內(nèi)垃圾對象很少，G1會優(yōu)先回收垃圾對象特別多的分區(qū)，這樣可以花費較少的時間來回收這些分區(qū)的垃圾，這也就是G1名字的由來，即首先收集垃圾最多的分區(qū)。

新生代其實并不是適用于這種算法的，依然是在新生代滿了的時候，對整個新生代進(jìn)行回收——整個新生代中的對象，要么被回收、要么晉升，至于新生代也采取分區(qū)機制的原因，則是因為這樣跟老年代的策略統(tǒng)一，方便調(diào)整代的大小。

G1還是一種帶壓縮的收集器，在回收老年代的分區(qū)時，是將存活的對象從一個分區(qū)拷貝到另一個可用分區(qū)，這個拷貝的過程就實現(xiàn)了局部的壓縮。每個分區(qū)的大小從1M到32M不等，但是都是2的冥次方。

2. 收集集合（CSet）

一組可被回收的分區(qū)的集合。在CSet中存活的數(shù)據(jù)會在GC過程中被移動到另一個可用分區(qū)，CSet中的分區(qū)可以來自Eden空間、survivor空間、或者老年代。CSet會占用不到整個堆空間的1%大小。

3. 已記憶集合（RSet）

RSet記錄了其他Region中的對象引用本Region中對象的關(guān)系，屬于points-into結(jié)構(gòu)（誰引用了我的對象）。RSet的價值在于使得垃圾收集器不需要掃描整個堆找到誰引用了當(dāng)前分區(qū)中的對象，只需要掃描RSet即可。

如下圖所示，Region1和Region3中的對象都引用了Region2中的對象，因此在Region2的RSet中記錄了這兩個引用。

?

RSet的示意圖

摘一段R大的解釋：G1 GC則是在points-out的card table之上再加了一層結(jié)構(gòu)來構(gòu)成points-into RSet：每個region會記錄下到底哪些別的region有指向自己的指針，而這些指針分別在哪些card的范圍內(nèi)。 這個RSet其實是一個hash table，key是別的region的起始地址，value是一個集合，里面的元素是card table的index。 舉例來說，如果region A的RSet里有一項的key是region B，value里有index為1234的card，它的意思就是region B的一個card里有引用指向region A。所以對region A來說，該RSet記錄的是points-into的關(guān)系；而card table仍然記錄了points-out的關(guān)系。

4. Snapshot-At-The-Beginning(SATB)

SATB是維持并發(fā)GC的正確性的一個手段，G1GC的并發(fā)理論基礎(chǔ)就是SATB，SATB是由Taiichi Yuasa為增量式標(biāo)記清除垃圾收集器設(shè)計的一個標(biāo)記算法。Yuasa的SATAB的標(biāo)記優(yōu)化主要針對標(biāo)記-清除垃圾收集器的并發(fā)標(biāo)記階段。按照R大的說法：CMS的incremental update設(shè)計使得它在remark階段必須重新掃描所有線程棧和整個young gen作為root；G1的SATB設(shè)計在remark階段則只需要掃描剩下的satb_mark_queue。

SATB算法創(chuàng)建了一個對象圖，它是堆的一個邏輯“快照”。標(biāo)記數(shù)據(jù)結(jié)構(gòu)包括了兩個位圖：previous位圖和next位圖。previous位圖保存了最近一次完成的標(biāo)記信息，并發(fā)標(biāo)記周期會創(chuàng)建并更新next位圖，隨著時間的推移，previous位圖會越來越過時，最終在并發(fā)標(biāo)記周期結(jié)束的時候，next位圖會將previous位圖覆蓋掉。
下面我們以幾個圖例來描述SATB算法的過程：

在并發(fā)周期開始之前，NTAMS字段被設(shè)置到每個分區(qū)當(dāng)前的頂部，并發(fā)周期啟動后分配的對象會被放在TAMS之前（圖里下邊的部分），同時被明確定義為隱式存活對象，而TAMS之后（圖里上邊的部分）的對象則需要被明確地標(biāo)記。

?

初始標(biāo)記過程中的一個堆分區(qū)

并發(fā)標(biāo)記過程中的堆分區(qū)

?

并發(fā)標(biāo)記過程中的對分區(qū)

位于堆分區(qū)的Bottom和PTAMS之間的對象都會被標(biāo)記并記錄在previous位圖中；

?

位于Bottom和PTAMS之間的對象都會被標(biāo)記在previous位圖中

位于堆分區(qū)的Top和PATMS之間的對象均為隱式存活對象，同時也記錄在previous位圖中；

?

隱式存活標(biāo)記，是一種增量標(biāo)記

在重新標(biāo)記階段的最后，所有NTAMS之前的對象都會被標(biāo)記

?

重新標(biāo)記

在并發(fā)標(biāo)記階段分配的對象會被分配到NTAMS之后的空間，它們會作為隱式存活對象被記錄在next位圖中。一次并發(fā)標(biāo)記周期完成后，這個next位圖會覆蓋previous位圖，然后將next位圖清空。

?

開始并發(fā)標(biāo)記后的對象會被識別為隱式存活對象，放在next位圖中

SATB是一個快照標(biāo)記算法，在并發(fā)標(biāo)記進(jìn)行的過程中，垃圾收集器（Collecotr）和應(yīng)用程序（Mutator）都在活動，如果一個對象還沒被mark到，這時候Mutator就修改了它的引用，那么這時候拿到的快照就是不完整的了，如何解決這個問題呢?

G1 GC使用了SATB write barrier來解決這個問題——在并發(fā)標(biāo)記過程中，將該對象的舊的引用記錄在一個SATB日志對列或緩沖區(qū)中。去翻G1的代碼，卻發(fā)現(xiàn)實際代碼如下——只該對象入隊列，并沒有將整個修改過程放在寫屏障之間完成。

??//?hotspot/src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.hpp//?This?notes?that?we?don't?need?to?access?any?BarrierSet?data//?structures,?so?this?can?be?called?from?a?static?context.template?<class?T>?static?void?write_ref_field_pre_static(T*?field,?oop?newVal)?{T?heap_oop?=?oopDesc::load_heap_oop(field);if?(!oopDesc::is_null(heap_oop))?{enqueue(oopDesc::decode_heap_oop(heap_oop));}}

enqueue的真正代碼在hotspot/src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp中，這里使用JavaThread::satb_mark_queue_set().is_active()判斷是否處于并發(fā)標(biāo)記周期。

void?G1SATBCardTableModRefBS::enqueue(oop?pre_val)?{//?Nulls?should?have?been?already?filtered.assert(pre_val->is_oop(true),?"Error");if?(!JavaThread::satb_mark_queue_set().is_active())?return;Thread*?thr?=?Thread::current();if?(thr->is_Java_thread())?{JavaThread*?jt?=?(JavaThread*)thr;//將舊值入隊jt->satb_mark_queue().enqueue(pre_val);}?else?{MutexLockerEx?x(Shared_SATB_Q_lock,?Mutex::_no_safepoint_check_flag);JavaThread::satb_mark_queue_set().shared_satb_queue()->enqueue(pre_val);} }

stab_mark_queue.enqueue方法首先嘗試將以前的值記錄在一個緩沖區(qū)中，如果這個緩沖區(qū)已經(jīng)滿了，就會將當(dāng)期這個SATB緩沖區(qū)“退休”并放入全局列表中，然后再給線程分配一個新的SATB緩沖區(qū)。并發(fā)標(biāo)記線程會定期檢查和處理那些“被填滿”的緩沖區(qū)。

三、G1的過程

1. 四個操作

G1收集器的收集活動主要有四種操作：

• 新生代垃圾收集

• 后臺收集、并發(fā)周期

• 混合式垃圾收集

• 必要時候的Full GC

第一、新生代垃圾收集的圖例如下：

?

• Eden區(qū)耗盡的時候就會觸發(fā)新生代收集，新生代垃圾收集會對整個新生代進(jìn)行回收

• 新生代垃圾收集期間，整個應(yīng)用STW

• 新生代垃圾收集是由多線程并發(fā)執(zhí)行的

• 新生代收集結(jié)束后依然存活的對象，會被拷貝到一個新的Survivor分區(qū)，或者是老年代。

G1設(shè)計了一個標(biāo)記閾值，它描述的是總體Java堆大小的百分比，默認(rèn)值是45，這個值可以通過命令-XX:InitiatingHeapOccupancyPercent(IHOP)來調(diào)整，一旦達(dá)到這個閾值就回觸發(fā)一次并發(fā)收集周期。注意：這里的百分比是針對整個堆大小的百分比，而CMS中的CMSInitiatingOccupancyFraction命令選型是針對老年代的百分比。并發(fā)收集周期的圖例如下：

?

在上圖中有幾個情況需要注意：

1、新生代的空間占用情況發(fā)生了變化——在并發(fā)收集周期中，至少有一次（很可能是多次）新生代垃圾收集；

2、注意到一些分區(qū)被標(biāo)記為X，這些分區(qū)屬于老年代，它們就是標(biāo)記周期找出的包含最多垃圾的分區(qū)（注意：它們內(nèi)部仍然保留著數(shù)據(jù)）；

3、老年代的空間占用在標(biāo)記周期結(jié)束后變得更多，這是因為在標(biāo)記周期期間，新生代的垃圾收集會晉升對象到老年代，而且標(biāo)記周期中并不會是否老年代的任何對象。

第二、G1的并發(fā)標(biāo)記周期包括多個階段：
并發(fā)標(biāo)記周期采用的算法是我們前文提到的SATB標(biāo)記算法，產(chǎn)出是找出一些垃圾對象最多的老年代分區(qū)。

1、初始標(biāo)記（initial-mark），在這個階段，應(yīng)用會經(jīng)歷STW，通常初始標(biāo)記階段會跟一次新生代收集一起進(jìn)行，換句話說——既然這兩個階段都需要暫停應(yīng)用，G1 GC就重用了新生代收集來完成初始標(biāo)記的工作。

?

在新生代垃圾收集中進(jìn)行初始標(biāo)記的工作，會讓停頓時間稍微長一點，并且會增加CPU的開銷。初始標(biāo)記做的工作是設(shè)置兩個TAMS變量（NTAMS和PTAMS）的值，所有在TAMS之上的對象在這個并發(fā)周期內(nèi)會被識別為隱式存活對象；

?

2、根分區(qū)掃描（root-region-scan），這個過程不需要暫停應(yīng)用，在初始標(biāo)記或新生代收集中被拷貝到survivor分區(qū)的對象，都需要被看做是根，這個階段G1開始掃描survivor分區(qū)，所有被survivor分區(qū)所引用的對象都會被掃描到并將被標(biāo)記。

?

survivor分區(qū)就是根分區(qū)，正因為這個，該階段不能發(fā)生新生代收集，如果掃描根分區(qū)時，新生代的空間恰好用盡，新生代垃圾收集必須等待根分區(qū)掃描結(jié)束才能完成。如果在日志中發(fā)現(xiàn)根分區(qū)掃描和新生代收集的日志交替出現(xiàn)，就說明當(dāng)前應(yīng)用需要調(diào)優(yōu)。

?

3、并發(fā)標(biāo)記階段（concurrent-mark），并發(fā)標(biāo)記階段是多線程的，我們可以通過-XX:ConcGCThreads來設(shè)置并發(fā)線程數(shù)，默認(rèn)情況下，G1垃圾收集器會將這個線程總數(shù)設(shè)置為并行垃圾線程數(shù)（-XX:ParallelGCThreads）的四分之一；并發(fā)標(biāo)記會利用trace算法找到所有活著的對象，并記錄在一個bitmap中，因為在TAMS之上的對象都被視為隱式存活，因此我們只需要遍歷那些在TAMS之下的；

?

記錄在標(biāo)記的時候發(fā)生的引用改變，SATB的思路是在開始的時候設(shè)置一個快照，然后假定這個快照不改變，根據(jù)這個快照去進(jìn)行trace，這時候如果某個對象的引用發(fā)生變化，就需要通過pre-write barrier logs將該對象的舊的值記錄在一個SATB緩沖區(qū)中，如果這個緩沖區(qū)滿了，就把它加到一個全局的列表中——G1會有并發(fā)標(biāo)記的線程定期去處理這個全局列表。

?

4、重新標(biāo)記階段（remarking），重新標(biāo)記階段是最后一個標(biāo)記階段，需要暫停整個應(yīng)用，G1垃圾收集器會處理掉剩下的SATB日志緩沖區(qū)和所有更新的引用，同時G1垃圾收集器還會找出所有未被標(biāo)記的存活對象。這個階段還會負(fù)責(zé)引用處理等工作。

?

5、清理階段（cleanup），清理階段真正回收的內(nèi)存很小，截止到這個階段,G1垃圾收集器主要是標(biāo)記處哪些老年代分區(qū)可以回收，將老年代按照它們的存活度（liveness）從小到大排列。

?

這個過程還會做幾個事情：識別出所有空閑的分區(qū)、RSet梳理、將不用的類從metaspace中卸載、回收巨型對象等等。識別出每個分區(qū)里存活的對象有個好處是在遇到一個完全空閑的分區(qū)時，它的RSet可以立即被清理，同時這個分區(qū)可以立刻被回收并釋放到空閑隊列中，而不需要再放入CSet等待混合收集階段回收；梳理RSet有助于發(fā)現(xiàn)無用的引用。

第三、混合收集只會回收一部分老年代分區(qū)，下圖是第一次混合收集前后的堆情況對比。

?

?

混合收集會執(zhí)行多次，一直運行到（幾乎）所有標(biāo)記點老年代分區(qū)都被回收，在這之后就會恢復(fù)到常規(guī)的新生代垃圾收集周期。當(dāng)整個堆的使用率超過指定的百分比時，G1 GC會啟動新一輪的并發(fā)標(biāo)記周期。在混合收集周期中，對于要回收的分區(qū)，會將該分區(qū)中存活的數(shù)據(jù)拷貝到另一個分區(qū)，這也是為什么G1收集器最終出現(xiàn)碎片化的頻率比CMS收集器小得多的原因——以這種方式回收對象，實際上伴隨著針對當(dāng)前分區(qū)的壓縮。

2. 兩個模式

G1收集器的模式主要有兩種：

• Young GC（新生代垃圾收集）

• Mixed GC（混合垃圾收集）

在R大的帖子中，給出了一個假象的G1垃圾收集運行過程，如下圖所示，在結(jié)合上一小節(jié)的細(xì)節(jié)，就可以將G1 GC的正常過程理解清楚了。

?

3. 巨型對象的管理

巨型對象：在G1中，如果一個對象的大小超過分區(qū)大小的一半，該對象就被定義為巨型對象（Humongous Object）。巨型對象時直接分配到老年代分區(qū)，如果一個對象的大小超過一個分區(qū)的大小，那么會直接在老年代分配兩個連續(xù)的分區(qū)來存放該巨型對象。巨型分區(qū)一定是連續(xù)的，分配之后也不會被移動——沒啥益處。

由于巨型對象的存在，G1的堆中的分區(qū)就分成了三種類型：新生代分區(qū)、老年代分區(qū)和巨型分區(qū)，如下圖所示：

?

如果一個巨型對象跨越兩個分區(qū)，開始的那個分區(qū)被稱為“開始巨型”，后面的分區(qū)被稱為“連續(xù)巨型”，這樣最后一個分區(qū)的一部分空間是被浪費掉的，如果有很多巨型對象都剛好比分區(qū)大小多一點，就會造成很多空間的浪費，從而導(dǎo)致堆的碎片化。如果你發(fā)現(xiàn)有很多由于巨型對象分配引起的連續(xù)的并發(fā)周期，并且堆已經(jīng)碎片化（明明空間夠，但是觸發(fā)了FULL GC），可以考慮調(diào)整-XX:G1HeapRegionSize參數(shù)，減少或消除巨型對象的分配。

關(guān)于巨型對象的回收：在JDK8u40之前，巨型對象的回收只能在并發(fā)收集周期的清除階段或FULL GC過程中過程中被回收，在JDK8u40（包括這個版本）之后，一旦沒有任何其他對象引用巨型對象，那么巨型對象也可以在年輕代收集中被回收。

4. G1執(zhí)行過程中的異常情況

并發(fā)標(biāo)記周期開始后的FULL GC

G1啟動了標(biāo)記周期，但是在并發(fā)標(biāo)記完成之前，就發(fā)生了Full GC，日志常常如下所示：

51.408:?[GC?concurrent-mark-start] 65.473:?[Full?GC?4095M->1395M(4096M),?6.1963770?secs][Times:?user=7.87?sys=0.00,?real=6.20?secs] 71.669:?[GC?concurrent-mark-abort]

GC concurrent-mark-start開始之后就發(fā)生了FULL GC，這說明針對老年代分區(qū)的回收速度比較慢，或者說對象過快得從新生代晉升到老年代，或者說是有很多大對象直接在老年代分配。針對上述原因，我們可能需要做的調(diào)整有：調(diào)大整個堆的大小、更快得觸發(fā)并發(fā)回收周期、讓更多的回收線程參與到垃圾收集的動作中。

混合收集模式中的FULL GC

在GC日志中觀察到，在一次混合收集之后跟著一條FULL GC，這意味著混合收集的速度太慢，在老年代釋放出足夠多的分區(qū)之前，應(yīng)用程序就來請求比當(dāng)前剩余可分配空間大的內(nèi)存。針對這種情況我們可以做的調(diào)整：增加每次混合收集收集掉的老年代分區(qū)個數(shù)；增加并發(fā)標(biāo)記的線程數(shù)；提高混合收集發(fā)生的頻率。

疏散失敗（轉(zhuǎn)移失敗）

在新生代垃圾收集快結(jié)束時，找不到可用的分區(qū)接收存活下來的對象，常見如下的日志：

60.238:?[GC?pause?(young)?(to-space?overflow),?0.41546900?secs]

這意味著整個堆的碎片化已經(jīng)非常嚴(yán)重了，我們可以從以下幾個方面調(diào)整：（1）增加整個堆的大小——通過增加-XX:G1ReservePercent選項的值（并相應(yīng)增加總的堆大小），為“目標(biāo)空間”增加預(yù)留內(nèi)存量;（2）通過減少?-XX:InitiatingHeapOccupancyPercent提前啟動標(biāo)記周期；（3）
你也可以通過增加-XX:ConcGCThreads選項的值來增加并發(fā)標(biāo)記線程的數(shù)目；

巨型對象分配失敗

如果在GC日志中看到莫名其妙的FULL GC日志，又對應(yīng)不到上述講過的幾種情況，那么就可以懷疑是巨型對象分配導(dǎo)致的，這里我們可以考慮使用jmap命令進(jìn)行堆dump，然后通過MAT對堆轉(zhuǎn)儲文件進(jìn)行分析。關(guān)于堆轉(zhuǎn)儲文件的分析技巧，后續(xù)會有專門的文章介紹。

四、G1的調(diào)優(yōu)

G1的調(diào)優(yōu)目標(biāo)主要是在避免FULL GC和疏散失敗的前提下，盡量實現(xiàn)較短的停頓時間和較高的吞吐量。關(guān)于G1 GC的調(diào)優(yōu)，需要記住以下幾點：

1、不要自己顯式設(shè)置新生代的大小（用Xmn或-XX:NewRatio參數(shù)），如果顯式設(shè)置新生代的大小，會導(dǎo)致目標(biāo)時間這個參數(shù)失效。

?

2、由于G1收集器自身已經(jīng)有一套預(yù)測和調(diào)整機制了，因此我們首先的選擇是相信它，即調(diào)整-XX:MaxGCPauseMillis=N參數(shù)，這也符合G1的目的——讓GC調(diào)優(yōu)盡量簡單，這里有個取舍：如果減小這個參數(shù)的值，就意味著會調(diào)小新生代的大小，也會導(dǎo)致新生代GC發(fā)生得更頻繁，同時，還會導(dǎo)致混合收集周期中回收的老年代分區(qū)減少，從而增加FULL GC的風(fēng)險。這個時間設(shè)置得越短，應(yīng)用的吞吐量也會受到影響。

?

3、針對混合垃圾收集的調(diào)優(yōu)。如果調(diào)整這期望的最大暫停時間這個參數(shù)還是無法解決問題，即在日志中仍然可以看到FULL GC的現(xiàn)象，那么就需要自己手動做一些調(diào)整，可以做的調(diào)整包括：

?

1）調(diào)整G1垃圾收集的后臺線程數(shù)，通過設(shè)置-XX:ConcGCThreads=n這個參數(shù)，可以增加后臺標(biāo)記線程的數(shù)量，幫G1贏得這場你追我趕的游戲；

?

2）調(diào)整G1垃圾收集器并發(fā)周期的頻率，如果讓G1更早得啟動垃圾收集，也可以幫助G1贏得這場比賽，那么可以通過設(shè)置-XX:InitiatingHeapOccupancyPercent這個參數(shù)來實現(xiàn)這個目標(biāo)，如果將這個參數(shù)調(diào)小，G1就會更早得觸發(fā)并發(fā)垃圾收集周期。

?

這個值需要謹(jǐn)慎設(shè)置：如果這個參數(shù)設(shè)置得太高，會導(dǎo)致FULL GC出現(xiàn)得頻繁；如果這個值設(shè)置得過小，又會導(dǎo)致G1頻繁得進(jìn)行并發(fā)收集，白白浪費CPU資源。通過GC日志可以通過一個點來判斷GC是否正?！谝惠啿l(fā)周期結(jié)束后，需要確保堆剩下的空間小于InitiatingHeapOccupancyPercent的值。

?

3）調(diào)整G1垃圾收集器的混合收集的工作量，即在一次混合垃圾收集中盡量多處理一些分區(qū)，可以從另外一方面提高混合垃圾收集的頻率。在一次混合收集中可以回收多少分區(qū)，取決于三個因素：

?

（1）有多少個分區(qū)被認(rèn)定為垃圾分區(qū)，-XX:G1MixedGCLiveThresholdPercent=n這個參數(shù)表示如果一個分區(qū)中的存活對象比例超過n，就不會被挑選為垃圾分區(qū)，因此可以通過這個參數(shù)控制每次混合收集的分區(qū)個數(shù)，這個參數(shù)的值越大，某個分區(qū)越容易被當(dāng)做是垃圾分區(qū)；

?

（2）G1在一個并發(fā)周期中，最多經(jīng)歷幾次混合收集周期，這個可以通過-XX:G1MixedGCCountTarget=n設(shè)置，默認(rèn)是8，如果減小這個值，可以增加每次混合收集收集的分區(qū)數(shù)，但是可能會導(dǎo)致停頓時間過長；

?

（3）期望的GC停頓的最大值，由MaxGCPauseMillis參數(shù)確定，默認(rèn)值是200ms，在混合收集周期內(nèi)的停頓時間是向上規(guī)整的，如果實際運行時間比這個參數(shù)小，那么G1就能收集更多的分區(qū)。

?

五、G1的最佳實踐

1. 關(guān)鍵參數(shù)項

• -XX:+UseG1GC，告訴JVM使用G1垃圾收集器

• -XX:MaxGCPauseMillis=200，設(shè)置GC暫停時間的目標(biāo)最大值，這是個柔性的目標(biāo)，JVM會盡力達(dá)到這個目標(biāo)

• -XX:INitiatingHeapOccupancyPercent=45，如果整個堆的使用率超過這個值，G1會觸發(fā)一次并發(fā)周期。記住這里針對的是整個堆空間的比例，而不是某個分代的比例。

2. 最佳實踐

不要設(shè)置年輕代的大小

通過-Xmn顯式設(shè)置年輕代的大小，會干擾G1收集器的默認(rèn)行為：

• G1不再以設(shè)定的暫停時間為目標(biāo)，換句話說，如果設(shè)置了年輕代的大小，就無法實現(xiàn)自適應(yīng)的調(diào)整來達(dá)到指定的暫停時間這個目標(biāo)

• G1不能按需擴(kuò)大或縮小年輕代的大小

?

響應(yīng)時間度量

不要根據(jù)平均響應(yīng)時間（ART）來設(shè)置-XX:MaxGCPauseMillis=n這個參數(shù)，應(yīng)該設(shè)置希望90%的GC都可以達(dá)到的暫停時間。這意味著90%的用戶請求不會超過這個響應(yīng)時間，記住，這個值是一個目標(biāo)，但是G1并不保證100%的GC暫停時間都可以達(dá)到這個目標(biāo)

3. G1 GC的參數(shù)選項

參數(shù)名含義默認(rèn)值

-XX:+UseG1GC	使用G1收集器	JDK1.8中還需要顯式指定
-XX:MaxGCPauseMillis=n	設(shè)置一個期望的最大GC暫停時間，這是一個柔性的目標(biāo)，JVM會盡力去達(dá)到這個目標(biāo)	200
-XX:InitiatingHeapOccupancyPercent=n	當(dāng)整個堆的空間使用百分比超過這個值時，就會觸發(fā)一次并發(fā)收集周期，記住是整個堆	45
-XX:NewRatio=n	新生代和老年代的比例	2
-XX:SurvivorRatio=n	Eden空間和Survivor空間的比例	8
-XX:MaxTenuringThreshold=n	對象在新生代中經(jīng)歷的最多的新生代收集，或者說最大的歲數(shù)	G1中是15
-XX:ParallelGCThreads=n	設(shè)置垃圾收集器的并行階段的垃圾收集線程數(shù)	不同的平臺有不同的值
-XX:ConcGCThreads=n	設(shè)置垃圾收集器并發(fā)執(zhí)行GC的線程數(shù)	n一般是ParallelGCThreads的四分之一
-XX:G1ReservePercent=n	設(shè)置作為空閑空間的預(yù)留內(nèi)存百分比，以降低目標(biāo)空間溢出（疏散失敗）的風(fēng)險。默認(rèn)值是 10%。增加或減少這個值，請確保對總的 Java 堆調(diào)整相同的量	10
-XX:G1HeapRegionSize=n	分區(qū)的大小	堆內(nèi)存大小的1/2000，單位是MB，值是2的冪，范圍是1MB到32MB之間
-XX:G1HeapWastePercent=n	設(shè)置您愿意浪費的堆百分比。如果可回收百分比小于堆廢物百分比，JavaHotSpotVM不會啟動混合垃圾回收周期（注意，這個參數(shù)可以用于調(diào)整混合收集的頻率）。	JDK1.8是5
-XX:G1MixedGCCountTarget=8	設(shè)置并發(fā)周期后需要執(zhí)行多少次混合收集，如果混合收集中STW的時間過長，可以考慮增大這個參數(shù)。（注意：這個可以用來調(diào)整每次混合收集中回收掉老年代分區(qū)的多少，即調(diào)節(jié)混合收集的停頓時間）	8
-XX:G1MixedGCLiveThresholdPercent=n	一個分區(qū)是否會被放入mix GC的CSet的閾值。對于一個分區(qū)來說，它的存活對象率如果超過這個比例，則改分區(qū)不會被列入mixed gc的CSet中	JDK1.6和1.7是65，JDK1.8是85

常見問題

1、Young GC、Mixed GC和Full GC的區(qū)別？
答：Young GC的CSet中只包括年輕代的分區(qū)，Mixed GC的CSet中除了包括年輕代分區(qū)，還包括老年代分區(qū)；Full GC會暫停整個引用，同時對新生代和老年代進(jìn)行收集和壓縮。

2、ParallelGCThreads和ConcGCThreads的區(qū)別？
答：ParallelGCThreads指得是在STW階段，并行執(zhí)行垃圾收集動作的線程數(shù)，ParallelGCThreads的值一般等于邏輯CPU核數(shù)，如果CPU核數(shù)大于8，則設(shè)置為5/8 * cpus，在SPARC等大型機上這個系數(shù)是5/16。；ConcGCThreads指的是在并發(fā)標(biāo)記階段，并發(fā)執(zhí)行標(biāo)記的線程數(shù)，一般設(shè)置為ParallelGCThreads的四分之一。

3、write barrier在GC中的作用？如何理解G1 GC中write barrier的作用？
寫屏障是一種內(nèi)存管理機制，用在這樣的場景——當(dāng)代碼嘗試修改一個對象的引用時，在前面放上寫屏障就意味著將這個對象放在了寫屏障后面。

write barrier在GC中的作用有點復(fù)雜，我們這里以trace GC算法為例講下：trace GC有些算法是并發(fā)的，例如CMS和G1，即用戶線程和垃圾收集線程可以同時運行，即mutator一邊跑，collector一邊收集。這里有一個限制是：黑色的對象不應(yīng)該指向任何白色的對象。如果mutator視圖讓一個黑色的對象指向一個白色的對象，這個限制就會被打破，然后GC就會失敗。

針對這個問題有兩種解決思路：

（1）通過添加read barriers阻止mutator看到白色的對象；

（2）通過write barrier阻止mutator修改一個黑色的對象，讓它指向一個白色的對象。write barrier的解決方法就是講黑色的對象放到寫write barrier后面。如果真得發(fā)生了white-on-black這種寫需求，一般也有多種修正方法：增量得將白色的對象變灰，將黑色的對象重新置灰等等。

我理解，增量的變灰就是CMS和G1里并發(fā)標(biāo)記的過程，將黑色的對象重新變灰就是利用卡表或SATB的緩沖區(qū)將黑色的對象重新置灰的過程，當(dāng)然會在重新標(biāo)記中將所有灰色的對象處理掉。關(guān)于G1中write barrier的作用，可以參考R大的這個帖子里提到的：

?

4、G1里在并發(fā)標(biāo)記的時候，如果有對象的引用修改，要將舊的值寫到一個緩沖區(qū)中，這個動作前后會有一個write barrier，這段可否細(xì)說下？

答：這塊涉及到SATB標(biāo)記算法的原理，SATB是指start at the beginning，即在并發(fā)收集周期的第一個階段（初始標(biāo)記）是STW的，會給所有的分區(qū)做個快照，后面的掃描都是按照這個快照進(jìn)行；在并發(fā)標(biāo)記周期的第二個階段，并發(fā)標(biāo)記，這是收集線程和應(yīng)用線程同時進(jìn)行的，這時候應(yīng)用線程就可能修改了某些引用的值，導(dǎo)致上面那個快照不是完整的，因此G1就想了個辦法，我把在這個期間對對象引用的修改都記錄動作都記錄下來，有點像mysql的操作日志。

5、GC算法中的三色標(biāo)記算法怎么理解？
trace GC將對象分為三類：白色（垃圾收集器未探測到的對象）、灰色（活著的對象，但是依然沒有被垃圾收集器掃描過）、黑色（活著的對象，并且已經(jīng)被垃圾收集器掃描過）。垃圾收集器的工作過程，就是通過灰色對象的指針掃描它指向的白色對象，如果找到一個白色對象，就將它設(shè)置為灰色，如果某個灰色對象的可達(dá)對象已經(jīng)全部找完，就將它設(shè)置為黑色對象。當(dāng)在當(dāng)前集合中找不到灰色的對象時，就說明該集合的回收動作完成，然后所有白色的對象的都會被回收。

PS：這個問題來自參考資料17，我將原文也貼在下面：

For a tracing collector (marking or copying), one conceptually colours the data white (not yet seen by the collector), black (alive and scanned by the collector) and grey (alive but not yet scanned by the collector). The collector proceeds by scanning grey objects for pointers to white objects. The white objects found are turned grey, and the grey objects scanned are turned black. When there are no more grey objects, the collection is complete and all the white objects can be recycled.

參考資料

Understanding G1 GC Logs

Garbage First Garbage Collector Tuning

垃圾優(yōu)先型回收器調(diào)優(yōu)

Oracle的GC調(diào)優(yōu)文檔——G1

The Garbage-First Garbage Collector

《Java性能權(quán)威指南》

《Java性能調(diào)優(yōu)指南》

G1入門，O記官網(wǎng)的PPT

Java Hotspot G1 GC的一些關(guān)鍵技術(shù)

G1 GC的論文

R大關(guān)于G1 GC的帖子

Tips for Tuning the Garbage First Garbage Collector

Java性能調(diào)優(yōu)指南

Java性能權(quán)威指南

G1: What are the differences between mixed gc and full gc?

Part 1: Introduction to the G1 Garbage Collector

Collecting and reading G1 garbage collector logs - part 2

GC FAQ -- algorithms

總結(jié)

以上是生活随笔為你收集整理的可能是最全面的 Java G1学习笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。