當前位置：首頁 > 编程语言 > java >内容正文

java

Java Hotspot G1 GC的一些关键技术

發布時間：2024/1/17 java 37 豆豆

生活随笔收集整理的這篇文章主要介紹了 Java Hotspot G1 GC的一些关键技术小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

前言

G1 GC，全稱Garbage-First Garbage Collector，通過-XX:+UseG1GC參數來啟用，作為體驗版隨著JDK 6u14版本面世，在JDK 7u4版本發行時被正式推出，相信熟悉JVM的同學們都不會對它感到陌生。在JDK 9中，G1被提議設置為默認垃圾收集器（JEP 248）。在官網中，是這樣描述G1的：

The Garbage-First (G1) collector is a server-style garbage collector, targeted for multi-processor machines with large memories. It meets garbage collection (GC) pause time goals with a high probability, while achieving high throughput. The G1 garbage collector is fully supported in Oracle JDK 7 update 4 and later releases. The G1 collector is designed for applications that:

Can operate concurrently with applications threads like the CMS collector.
Compact free space without lengthy GC induced pause times.
Need more predictable GC pause durations.
Do not want to sacrifice a lot of throughput performance.
Do not require a much larger Java heap.

從官網的描述中，我們知道G1是一種服務器端的垃圾收集器，應用在多處理器和大容量內存環境中，在實現高吞吐量的同時，盡可能的滿足垃圾收集暫停時間的要求。它是專門針對以下應用場景設計的:

像CMS收集器一樣，能與應用程序線程并發執行。
整理空閑空間更快。
需要GC停頓時間更好預測。
不希望犧牲大量的吞吐性能。
不需要更大的Java Heap。

G1收集器的設計目標是取代CMS收集器，它同CMS相比，在以下方面表現的更出色：

G1是一個有整理內存過程的垃圾收集器，不會產生很多內存碎片。
G1的Stop The World(STW)更可控，G1在停頓時間上添加了預測機制，用戶可以指定期望停頓時間。

有了以上的特性，難怪有人說它是一款駕馭一切的垃圾收集器（G1: One Garbage Collector To Rule Them All）。本文帶大家來了解一下G1 GC的一些關鍵技術，為能正確的使用它，做好理論基礎的鋪墊。

G1中幾個重要概念

在G1的實現過程中，引入了一些新的概念，對于實現高吞吐、沒有內存碎片、收集時間可控等功能起到了關鍵作用。下面我們就一起看一下G1中的這幾個重要概念。

Region

傳統的GC收集器將連續的內存空間劃分為新生代、老年代和永久代（JDK 8去除了永久代，引入了元空間Metaspace），這種劃分的特點是各代的存儲地址（邏輯地址，下同）是連續的。如下圖所示：

而G1的各代存儲地址是不連續的，每一代都使用了n個不連續的大小相同的Region，每個Region占有一塊連續的虛擬內存地址。如下圖所示：

在上圖中，我們注意到還有一些Region標明了H，它代表Humongous，這表示這些Region存儲的是巨大對象（humongous object，H-obj），即大小大于等于region一半的對象。H-obj有如下幾個特征：

H-obj直接分配到了old gen，防止了反復拷貝移動。
H-obj在global concurrent marking階段的cleanup 和 full GC階段回收。
在分配H-obj之前先檢查是否超過 initiating heap occupancy percent和the marking threshold, 如果超過的話，就啟動global concurrent marking，為的是提早回收，防止 evacuation failures 和 full GC。

為了減少連續H-objs分配對GC的影響，需要把大對象變為普通的對象，建議增大Region size。

一個Region的大小可以通過參數-XX:G1HeapRegionSize設定，取值范圍從1M到32M，且是2的指數。如果不設定，那么G1會根據Heap大小自動決定。相關的設置代碼如下：

// share/vm/gc_implementation/g1/heapRegion.cpp // Minimum region size; we won't go lower than that. // We might want to decrease this in the future, to deal with small // heaps a bit more efficiently. #define MIN_REGION_SIZE ( 1024 * 1024 ) // Maximum region size; we don't go higher than that. There's a good // reason for having an upper bound. We don't want regions to get too // large, otherwise cleanup's effectiveness would decrease as there // will be fewer opportunities to find totally empty regions after // marking. #define MAX_REGION_SIZE ( 32 * 1024 * 1024 ) // The automatic region size calculation will try to have around this // many regions in the heap (based on the min heap size). #define TARGET_REGION_NUMBER 2048 void HeapRegion::setup_heap_region_size(size_t initial_heap_size, size_t max_heap_size) {uintx region_size = G1HeapRegionSize;if (FLAG_IS_DEFAULT(G1HeapRegionSize)) {size_t average_heap_size = (initial_heap_size + max_heap_size) / 2;region_size = MAX2(average_heap_size / TARGET_REGION_NUMBER,(uintx) MIN_REGION_SIZE);}int region_size_log = log2_long((jlong) region_size);// Recalculate the region size to make sure it's a power of// 2. This means that region_size is the largest power of 2 that's// <= what we've calculated so far.region_size = ((uintx)1 << region_size_log);// Now make sure that we don't go over or under our limits.if (region_size < MIN_REGION_SIZE) {region_size = MIN_REGION_SIZE;} else if (region_size > MAX_REGION_SIZE) {region_size = MAX_REGION_SIZE;} }

SATB

全稱是Snapshot-At-The-Beginning，由字面理解，是GC開始時活著的對象的一個快照。它是通過Root Tracing得到的，作用是維持并發GC的正確性。
那么它是怎么維持并發GC的正確性的呢？根據三色標記算法，我們知道對象存在三種狀態：

白：對象沒有被標記到，標記階段結束后，會被當做垃圾回收掉。
灰：對象被標記了，但是它的field還沒有被標記或標記完。
黑：對象被標記了，且它的所有field也被標記完了。

由于并發階段的存在，Mutator和Garbage Collector線程同時對對象進行修改，就會出現白對象漏標的情況，這種情況發生的前提是：

Mutator賦予一個黑對象該白對象的引用。
Mutator刪除了所有從灰對象到該白對象的直接或者間接引用。

對于第一個條件，在并發標記階段，如果該白對象是new出來的，并沒有被灰對象持有，那么它會不會被漏標呢？Region中有兩個top-at-mark-start（TAMS）指針，分別為prevTAMS和nextTAMS。在TAMS以上的對象是新分配的，這是一種隱式的標記。對于在GC時已經存在的白對象，如果它是活著的，它必然會被另一個對象引用，即條件二中的灰對象。如果灰對象到白對象的直接引用或者間接引用被替換了，或者刪除了，白對象就會被漏標，從而導致被回收掉，這是非常嚴重的錯誤，所以SATB破壞了第二個條件。也就是說，一個對象的引用被替換時，可以通過write barrier 將舊引用記錄下來。

// 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));} } // share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp 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);} }

SATB也是有副作用的，如果被替換的白對象就是要被收集的垃圾，這次的標記會讓它躲過GC，這就是float garbage。因為SATB的做法精度比較低，所以造成的float garbage也會比較多。

RSet

全稱是Remembered Set，是輔助GC過程的一種結構，典型的空間換時間工具，和Card Table有些類似。還有一種數據結構也是輔助GC的：Collection Set（CSet），它記錄了GC要收集的Region集合，集合里的Region可以是任意年代的。在GC的時候，對于old->young和old->old的跨代對象引用，只要掃描對應的CSet中的RSet即可。
邏輯上說每個Region都有一個RSet，RSet記錄了其他Region中的對象引用本Region中對象的關系，屬于points-into結構（誰引用了我的對象）。而Card Table則是一種points-out（我引用了誰的對象）的結構，每個Card 覆蓋一定范圍的Heap（一般為512Bytes）。G1的RSet是在Card Table的基礎上實現的：每個Region會記錄下別的Region有指向自己的指針，并標記這些指針分別在哪些Card的范圍內。這個RSet其實是一個Hash Table，Key是別的Region的起始地址，Value是一個集合，里面的元素是Card Table的Index。

下圖表示了RSet、Card和Region的關系（出處）：

上圖中有三個Region，每個Region被分成了多個Card，在不同Region中的Card會相互引用，Region1中的Card中的對象引用了Region2中的Card中的對象，藍色實線表示的就是points-out的關系，而在Region2的RSet中，記錄了Region1的Card，即紅色虛線表示的關系，這就是points-into。
而維系RSet中的引用關系靠post-write barrier和Concurrent refinement threads來維護，操作偽代碼如下（出處）：

void oop_field_store(oop* field, oop new_value) {pre_write_barrier(field); // pre-write barrier: for maintaining SATB invariant*field = new_value; // the actual storepost_write_barrier(field, new_value); // post-write barrier: for tracking cross-region reference }

post-write barrier記錄了跨Region的引用更新，更新日志緩沖區則記錄了那些包含更新引用的Cards。一旦緩沖區滿了，Post-write barrier就停止服務了，會由Concurrent refinement threads處理這些緩沖區日志。
RSet究竟是怎么輔助GC的呢？在做YGC的時候，只需要選定young generation region的RSet作為根集，這些RSet記錄了old->young的跨代引用，避免了掃描整個old generation。而mixed gc的時候，old generation中記錄了old->old的RSet，young->old的引用由掃描全部young generation region得到，這樣也不用掃描全部old generation region。所以RSet的引入大大減少了GC的工作量。

Pause Prediction Model

Pause Prediction Model 即停頓預測模型。它在G1中的作用是：

G1 uses a pause prediction model to meet a user-defined pause time target and selects the number of regions to collect based on the specified pause time target.

G1 GC是一個響應時間優先的GC算法，它與CMS最大的不同是，用戶可以設定整個GC過程的期望停頓時間，參數-XX:MaxGCPauseMillis指定一個G1收集過程目標停頓時間，默認值200ms，不過它不是硬性條件，只是期望值。那么G1怎么滿足用戶的期望呢？就需要這個停頓預測模型了。G1根據這個模型統計計算出來的歷史數據來預測本次收集需要選擇的Region數量，從而盡量滿足用戶設定的目標停頓時間。
停頓預測模型是以衰減標準偏差為理論基礎實現的：

// share/vm/gc_implementation/g1/g1CollectorPolicy.hpp double get_new_prediction(TruncatedSeq* seq) {return MAX2(seq->davg() + sigma() * seq->dsd(),seq->davg() * confidence_factor(seq->num())); }

在這個預測計算公式中：davg表示衰減均值，sigma()返回一個系數，表示信賴度，dsd表示衰減標準偏差，confidence_factor表示可信度相關系數。而方法的參數TruncateSeq，顧名思義，是一個截斷的序列，它只跟蹤了序列中的最新的n個元素。

在G1 GC過程中，每個可測量的步驟花費的時間都會記錄到TruncateSeq（繼承了AbsSeq）中，用來計算衰減均值、衰減變量，衰減標準偏差等：

// src/share/vm/utilities/numberSeq.cppvoid AbsSeq::add(double val) {if (_num == 0) {// if the sequence is empty, the davg is the same as the value_davg = val;// and the variance is 0_dvariance = 0.0;} else {// otherwise, calculate both_davg = (1.0 - _alpha) * val + _alpha * _davg;double diff = val - _davg;_dvariance = (1.0 - _alpha) * diff * diff + _alpha * _dvariance;} }

比如要預測一次GC過程中，RSet的更新時間，這個操作主要是將Dirty Card加入到RSet中，具體原理參考前面的RSet。每個Dirty Card的時間花費通過_cost_per_card_ms_seq來記錄，具體預測代碼如下：

// share/vm/gc_implementation/g1/g1CollectorPolicy.hppdouble predict_rs_update_time_ms(size_t pending_cards) {return (double) pending_cards * predict_cost_per_card_ms();}double predict_cost_per_card_ms() {return get_new_prediction(_cost_per_card_ms_seq);}

get_new_prediction就是我們開頭說的方法，現在大家應該基本明白停頓預測模型的實現原理了。

GC過程

講完了一些基本概念，下面我們就來看看G1的GC過程是怎樣的。

G1 GC模式

G1提供了兩種GC模式，Young GC和Mixed GC，兩種都是完全Stop The World的。

Young GC：選定所有年輕代里的Region。通過控制年輕代的region個數，即年輕代內存大小，來控制young GC的時間開銷。
Mixed GC：選定所有年輕代里的Region，外加根據global concurrent marking統計得出收集收益高的若干老年代Region。在用戶指定的開銷目標范圍內盡可能選擇收益高的老年代Region。

由上面的描述可知，Mixed GC不是full GC，它只能回收部分老年代的Region，如果mixed GC實在無法跟上程序分配內存的速度，導致老年代填滿無法繼續進行Mixed GC，就會使用serial old GC（full GC）來收集整個GC heap。所以我們可以知道，G1是不提供full GC的。

上文中，多次提到了global concurrent marking，它的執行過程類似CMS，但是不同的是，在G1 GC中，它主要是為Mixed GC提供標記服務的，并不是一次GC過程的一個必須環節。global concurrent marking的執行過程分為四個步驟：

初始標記（initial mark，STW）。它標記了從GC Root開始直接可達的對象。
并發標記（Concurrent Marking）。這個階段從GC Root開始對heap中的對象標記，標記線程與應用程序線程并行執行，并且收集各個Region的存活對象信息。
最終標記（Remark，STW）。標記那些在并發標記階段發生變化的對象，將被回收。
清除垃圾（Cleanup）。清除空Region（沒有存活對象的），加入到free list。

第一階段initial mark是共用了Young GC的暫停，這是因為他們可以復用root scan操作，所以可以說global concurrent marking是伴隨Young GC而發生的。第四階段Cleanup只是回收了沒有存活對象的Region，所以它并不需要STW。

Young GC發生的時機大家都知道，那什么時候發生Mixed GC呢？其實是由一些參數控制著的，另外也控制著哪些老年代Region會被選入CSet。

G1HeapWastePercent：在global concurrent marking結束之后，我們可以知道old gen regions中有多少空間要被回收，在每次YGC之后和再次發生Mixed GC之前，會檢查垃圾占比是否達到此參數，只有達到了，下次才會發生Mixed GC。
G1MixedGCLiveThresholdPercent：old generation region中的存活對象的占比，只有在此參數之下，才會被選入CSet。
G1MixedGCCountTarget：一次global concurrent marking之后，最多執行Mixed GC的次數。
G1OldCSetRegionThresholdPercent：一次Mixed GC中能被選入CSet的最多old generation region數量。

除了以上的參數，G1 GC相關的其他主要的參數有：

參數含義

-XX:G1HeapRegionSize=n	設置Region大小，并非最終值
-XX:MaxGCPauseMillis	設置G1收集過程目標時間，默認值200ms，不是硬性條件
-XX:G1NewSizePercent	新生代最小值，默認值5%
-XX:G1MaxNewSizePercent	新生代最大值，默認值60%
-XX:ParallelGCThreads	STW期間，并行GC線程數
-XX:ConcGCThreads=n	并發標記階段，并行執行的線程數
-XX:InitiatingHeapOccupancyPercent	設置觸發標記周期的 Java 堆占用率閾值。默認值是45%。這里的java堆占比指的是non_young_capacity_bytes，包括old+humongous

GC日志

G1收集器的日志與其他收集器有很大不同，源于G1獨立的體系架構和數據結構，下面這兩段日志來源于美團點評的CRM系統線上生產環境。

Young GC日志

我們先來看看Young GC的日志：

{Heap before GC invocations=12 (full 1):garbage-first heap total 3145728K, used 336645K [0x0000000700000000, 0x00000007c0000000, 0x00000007c0000000)region size 1024K, 172 young (176128K), 13 survivors (13312K)Metaspace used 29944K, capacity 30196K, committed 30464K, reserved 1077248Kclass space used 3391K, capacity 3480K, committed 3584K, reserved 1048576K 2014-11-14T17:57:23.654+0800: 27.884: [GC pause (G1 Evacuation Pause) (young) Desired survivor size 11534336 bytes, new threshold 15 (max 15) - age 1: 5011600 bytes, 5011600 total27.884: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 1461, predicted base time: 35.25 ms, remaining time: 64.75 ms, target pause time: 100.00 ms]27.884: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 159 regions, survivors: 13 regions, predicted young region time: 44.09 ms]27.884: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 159 regions, survivors: 13 regions, old: 0 regions, predicted pause time: 79.34 ms, target pause time: 100.00 ms] , 0.0158389 secs][Parallel Time: 8.1 ms, GC Workers: 4][GC Worker Start (ms): Min: 27884.5, Avg: 27884.5, Max: 27884.5, Diff: 0.1][Ext Root Scanning (ms): Min: 0.4, Avg: 0.8, Max: 1.2, Diff: 0.8, Sum: 3.1][Update RS (ms): Min: 0.0, Avg: 0.3, Max: 0.6, Diff: 0.6, Sum: 1.4][Processed Buffers: Min: 0, Avg: 2.8, Max: 5, Diff: 5, Sum: 11][Scan RS (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 0.3][Code Root Scanning (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.6][Object Copy (ms): Min: 4.9, Avg: 5.1, Max: 5.2, Diff: 0.3, Sum: 20.4][Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0][GC Worker Other (ms): Min: 0.0, Avg: 0.4, Max: 1.3, Diff: 1.3, Sum: 1.4][GC Worker Total (ms): Min: 6.4, Avg: 6.8, Max: 7.8, Diff: 1.4, Sum: 27.2][GC Worker End (ms): Min: 27891.0, Avg: 27891.3, Max: 27892.3, Diff: 1.3][Code Root Fixup: 0.5 ms][Code Root Migration: 1.3 ms][Code Root Purge: 0.0 ms][Clear CT: 0.2 ms][Other: 5.8 ms][Choose CSet: 0.0 ms][Ref Proc: 5.0 ms][Ref Enq: 0.1 ms][Redirty Cards: 0.0 ms][Free CSet: 0.2 ms][Eden: 159.0M(159.0M)->0.0B(301.0M) Survivors: 13.0M->11.0M Heap: 328.8M(3072.0M)->167.3M(3072.0M)] Heap after GC invocations=13 (full 1):garbage-first heap total 3145728K, used 171269K [0x0000000700000000, 0x00000007c0000000, 0x00000007c0000000)region size 1024K, 11 young (11264K), 11 survivors (11264K)Metaspace used 29944K, capacity 30196K, committed 30464K, reserved 1077248Kclass space used 3391K, capacity 3480K, committed 3584K, reserved 1048576K }[Times: user=0.05 sys=0.01, real=0.02 secs]

每個過程的作用如下：

garbage-first heap total 3145728K, used 336645K [0x0000000700000000, 0x00000007c0000000, 0x00000007c0000000)
這行表示使用了G1垃圾收集器，total heap 3145728K，使用了336645K。
region size 1024K, 172 young (176128K), 13 survivors (13312K)
Region大小為1M，青年代占用了172個（共176128K），幸存區占用了13個（共13312K）。
Metaspace used 29944K, capacity 30196K, committed 30464K, reserved 1077248K
class space used 3391K, capacity 3480K, committed 3584K, reserved 1048576K
java 8的新特性，去掉永久區，添加了元數據區，這塊不是本文重點，不再贅述。需要注意的是，之所以有committed和reserved，是因為沒有設置MetaspaceSize=MaxMetaspaceSize。
[GC pause (G1 Evacuation Pause) (young)
GC原因，新生代minor GC。
[G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 1461, predicted base time: 35.25 ms, remaining time: 64.75 ms, target pause time: 100.00 ms]
發生minor GC和full GC時，所有相關region都是要回收的。而發生并發GC時，會根據目標停頓時間動態選擇部分垃圾對并多的Region回收，這一步就是選擇Region。_pending_cards是關于RSet的Card Table。predicted base time是預測的掃描card table時間。
[G1Ergonomics (CSet Construction) add young regions to CSet, eden: 159 regions, survivors: 13 regions, predicted young region time: 44.09 ms]
這一步是添加Region到collection set，新生代一共159個Region，13個幸存區Region，這也和之前的（172 young (176128K), 13 survivors (13312K)）吻合。預計收集時間是44.09 ms。
[G1Ergonomics (CSet Construction) finish choosing CSet, eden: 159 regions, survivors: 13 regions, old: 0 regions, predicted pause time: 79.34 ms, target pause time: 100.00 ms]
這一步是對上面兩步的總結。預計總收集時間79.34ms。
[Parallel Time: 8.1 ms, GC Workers: 4]
由于收集過程是多線程并行（并發）進行，這里是4個線程，總共耗時8.1ms（wall clock time）
[GC Worker Start (ms): Min: 27884.5, Avg: 27884.5, Max: 27884.5, Diff: 0.1]
收集線程開始的時間，使用的是相對時間，Min是最早開始時間，Avg是平均開始時間，Max是最晚開始時間，Diff是Max-Min（此處的0.1貌似有問題）
[Ext Root Scanning (ms): Min: 0.4, Avg: 0.8, Max: 1.2, Diff: 0.8, Sum: 3.1]
掃描Roots花費的時間，Sum表示total cpu time，下同。
[Update RS (ms): Min: 0.0, Avg: 0.3, Max: 0.6, Diff: 0.6, Sum: 1.4] [Processed Buffers: Min: 0, Avg: 2.8, Max: 5, Diff: 5, Sum: 11]
Update RS (ms)是每個線程花費在更新Remembered Set上的時間。
[Scan RS (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 0.3]
掃描CS中的region對應的RSet，因為RSet是points-into，所以這樣實現避免了掃描old generadion region，但是會產生float garbage。
[Code Root Scanning (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.6]
掃描code root耗時。code root指的是經過JIT編譯后的代碼里，引用了heap中的對象。引用關系保存在RSet中。
[Object Copy (ms): Min: 4.9, Avg: 5.1, Max: 5.2, Diff: 0.3, Sum: 20.4]
拷貝活的對象到新region的耗時。
[Termination (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
線程結束，在結束前，它會檢查其他線程是否還有未掃描完的引用，如果有，則"偷"過來，完成后再申請結束，這個時間是線程之前互相同步所花費的時間。
[GC Worker Other (ms): Min: 0.0, Avg: 0.4, Max: 1.3, Diff: 1.3, Sum: 1.4]
花費在其他工作上（未列出）的時間。
[GC Worker Total (ms): Min: 6.4, Avg: 6.8, Max: 7.8, Diff: 1.4, Sum: 27.2]
每個線程花費的時間和。
[GC Worker End (ms): Min: 27891.0, Avg: 27891.3, Max: 27892.3, Diff: 1.3]
每個線程結束的時間。
[Code Root Fixup: 0.5 ms]
用來將code root修正到正確的evacuate之后的對象位置所花費的時間。
[Code Root Migration: 1.3 ms]
更新code root 引用的耗時，code root中的引用因為對象的evacuation而需要更新。
[Code Root Purge: 0.0 ms]
清除code root的耗時，code root中的引用已經失效，不再指向Region中的對象，所以需要被清除。
[Clear CT: 0.2 ms]
清除card table的耗時。
[Other: 5.8 ms]
[Choose CSet: 0.0 ms]
[Ref Proc: 5.0 ms]
[Ref Enq: 0.1 ms]
[Redirty Cards: 0.0 ms]
[Free CSet: 0.2 ms]
其他事項共耗時5.8ms，其他事項包括選擇CSet，處理已用對象，引用入ReferenceQueues，釋放CSet中的region到free list。
[Eden: 159.0M(159.0M)->0.0B(301.0M) Survivors: 13.0M->11.0M Heap: 328.8M(3072.0M)->167.3M(3072.0M)]
新生代清空了，下次擴容到301MB。

global concurrent marking 日志

對于global concurrent marking過程，它的日志如下所示：

66955.252: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: occupancy higher than threshold, occupancy: 1449132032 bytes, allocation request: 579608 bytes, threshold: 1449 551430 bytes (45.00 %), source: concurrent humongous allocation] 2014-12-10T11:13:09.532+0800: 66955.252: Application time: 2.5750418 seconds66955.259: [G1Ergonomics (Concurrent Cycles) request concurrent cycle initiation, reason: requested by GC cause, GC cause: G1 Humongous Allocation] {Heap before GC invocations=1874 (full 4):garbage-first heap total 3145728K, used 1281786K [0x0000000700000000, 0x00000007c0000000, 0x00000007c0000000)region size 1024K, 171 young (175104K), 27 survivors (27648K)Metaspace used 116681K, capacity 137645K, committed 137984K, reserved 1171456Kclass space used 13082K, capacity 16290K, committed 16384K, reserved 1048576K66955.259: [G1Ergonomics (Concurrent Cycles) initiate concurrent cycle, reason: concurrent cycle initiation requested] 2014-12-10T11:13:09.539+0800: 66955.259: [GC pause (G1 Humongous Allocation) (young) (initial-mark) ……. 2014-12-10T11:13:09.597+0800: 66955.317: [GC concurrent-root-region-scan-start] 2014-12-10T11:13:09.597+0800: 66955.318: Total time for which application threads were stopped: 0.0655753 seconds 2014-12-10T11:13:09.610+0800: 66955.330: Application time: 0.0127071 seconds 2014-12-10T11:13:09.614+0800: 66955.335: Total time for which application threads were stopped: 0.0043882 seconds 2014-12-10T11:13:09.625+0800: 66955.346: [GC concurrent-root-region-scan-end, 0.0281351 secs] 2014-12-10T11:13:09.625+0800: 66955.346: [GC concurrent-mark-start] 2014-12-10T11:13:09.645+0800: 66955.365: Application time: 0.0306801 seconds 2014-12-10T11:13:09.651+0800: 66955.371: Total time for which application threads were stopped: 0.0061326 seconds 2014-12-10T11:13:10.212+0800: 66955.933: [GC concurrent-mark-end, 0.5871129 secs] 2014-12-10T11:13:10.212+0800: 66955.933: Application time: 0.5613792 seconds 2014-12-10T11:13:10.215+0800: 66955.935: [GC remark 66955.936: [GC ref-proc, 0.0235275 secs], 0.0320865 secs][Times: user=0.05 sys=0.00, real=0.03 secs] 2014-12-10T11:13:10.247+0800: 66955.968: Total time for which application threads were stopped: 0.0350098 seconds 2014-12-10T11:13:10.248+0800: 66955.968: Application time: 0.0001691 seconds 2014-12-10T11:13:10.250+0800: 66955.970: [GC cleanup 1178M->632M(3072M), 0.0060632 secs][Times: user=0.02 sys=0.00, real=0.01 secs] 2014-12-10T11:13:10.256+0800: 66955.977: Total time for which application threads were stopped: 0.0088462 seconds 2014-12-10T11:13:10.257+0800: 66955.977: [GC concurrent-cleanup-start] 2014-12-10T11:13:10.259+0800: 66955.979: [GC concurrent-cleanup-end, 0.0024743 secs

這次發生global concurrent marking的原因是：humongous allocation，上面提過在巨大對象分配之前，會檢測到old generation 使用占比是否超過了 initiating heap occupancy percent（45%），因為
1449132032(used)+ 579608(allocation request:) > 1449551430(threshold)，所以觸發了本次global concurrent marking。對于具體執行過程，上面的表格已經詳細講解了。值得注意的是上文中所說的initial mark往往伴隨著一次YGC，在日志中也有體現：GC pause (G1 Humongous Allocation) (young) (initial-mark)。

后記

因為篇幅的關系，也受限于能力水平，本文只是簡單了介紹了G1 GC的基本原理，很多細節沒有涉及到，所以說只能算是為研究和使用它的同學打開了一扇門。一個日本人專門寫了一本書《徹底解剖「G1GC」アルゴリズ》詳細的介紹了G1 GC，這本書也被作者放到了GitHub上，詳見參考文獻5。另外，莫樞在這方面也研究的比較多，讀者可以去高級語言虛擬機論壇向他請教，本文的很多內容也是我在此論壇上請教過后整理的。總而言之，G1是一款非常優秀的垃圾收集器，盡管還有些不完美（預測模型還不夠智能），但是希望有更多的同學來使用它，研究它，提出好的建議，讓它變的更加完善。

參考文獻

Getting Started with the G1 Garbage Collector

請教G1算法的原理

關于incremental update與SATB的一點理解

Tips for Tuning the Garbage First Garbage Collector

g1gc-impl-book

垃圾優先型垃圾回收器調優

Understanding G1 GC Logs

G1: One Garbage Collector To Rule Them All

總結

以上是生活随笔為你收集整理的Java Hotspot G1 GC的一些关键技术的全部內容，希望文章能夠幫你解決所遇到的問題。

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

上一篇： jvm系列(十一):Java 8-从持久
下一篇：对数据科学家来说最重要的算法和统计模型