原文
施工中

Hotspot Architecture

Hotspot虛擬機架構(gòu)

JVM主要組件包括類加載器，運行時數(shù)據(jù)區(qū)和執(zhí)行引擎。

Key Hotspot Components

關(guān)鍵組件

在進行性能調(diào)優(yōu)時，主要關(guān)注虛擬機的三個組件。java堆保存著對象實例，由JVM啟動時選定的GC進行維護。大部分調(diào)優(yōu)參數(shù)都涉及調(diào)整java堆及內(nèi)部各區(qū)域的大小、選擇最適合的GC。JIT編譯器對性能也有巨大影響，但新近的虛擬機很少需要針對它進行調(diào)優(yōu)。

Performance Basics

性能基礎(chǔ)

java應(yīng)用調(diào)優(yōu)一般關(guān)注兩個指標(biāo)：響應(yīng)時間和吞吐量。

Responsiveness

響應(yīng)時間

響應(yīng)時間指的是應(yīng)用對請求的響應(yīng)時間，如：

• 一個桌面應(yīng)用對時間的響應(yīng)時間
• 網(wǎng)站返回一個頁面的時間
• 數(shù)據(jù)庫查詢結(jié)果返回時間

對于專注于最小響應(yīng)時間的應(yīng)用，長時間停頓是無法接受的。

Throughput

吞吐量

吞吐量專注于應(yīng)用在一段時間的的最大工作量。如：

• 給定時間內(nèi)完成的事物數(shù)
• 每小時批處理程序能夠完成的任務(wù)
• 每小時數(shù)據(jù)庫可以完成的查詢操作數(shù)

較長停頓時間在此情況下是可以接受的。比起低響應(yīng)時間，吞吐量優(yōu)先應(yīng)用更看重一段時間內(nèi)的表現(xiàn)。

The G1 Garbage Collector

G1垃圾收集器

Garbage-First(G1)收集器時一款服務(wù)端垃圾收集器，主要針對多處理器、大內(nèi)存環(huán)境設(shè)計。在盡可能滿足GC停頓時間目標(biāo)的同時獲取更高的吞吐量。

G1的設(shè)計目標(biāo)是滿足：

• 像CMS那樣做到并發(fā)GC，提高GC并行和并發(fā)表現(xiàn)
• 沒有內(nèi)存碎片問題，內(nèi)存整理過程不需要延長GC時間，不需要虛擬機停頓STW
• 可預(yù)測的GC停頓時間
• 更高的吞吐量
• 在不增加堆內(nèi)存大小下更好地利用堆內(nèi)存

G1的遠(yuǎn)期目標(biāo)時替代CMS+ParNew（自適應(yīng)的、分代的、停頓-復(fù)制、標(biāo)記-清理并發(fā)垃圾回收器）組合。與CMS相比，G1優(yōu)點包括：G1是內(nèi)存整理虛擬機，G1通過對堆內(nèi)存劃分區(qū)域（region），分區(qū)管理，避免使用細(xì)粒度空閑列表來實現(xiàn)高效內(nèi)存整理；G1提供比CMS更加可預(yù)測的GC停頓時間，并允許用戶設(shè)定停頓時間目標(biāo)。

G1 Operational Overview

G1實現(xiàn)概覽

老式垃圾回收器(Serial,Parallel,CMS)統(tǒng)一將java堆分成大小固定的三部分：新生代、老年代和永久代。（開啟GC Ergonomics自適應(yīng)調(diào)整策略，如Parallel Scavange，可以動態(tài)調(diào)整新生代大小、eden與survivor比例）所有內(nèi)存對象最終都保存在這三個區(qū)域內(nèi)。

G1收集器將java堆均分成大小相同的區(qū)域（region，1M-32M，最多2000個，最大支持堆內(nèi)存64G）。一個或多個不連續(xù)的區(qū)域共同組成eden、survivor或old區(qū)，但大小不再固定，這為內(nèi)存應(yīng)用提供了極大地彈性。G1垃圾收集過程與CMS類似。G1在堆內(nèi)存中并發(fā)地對所有對象進行標(biāo)記，決定對象的可達性。經(jīng)過全局標(biāo)記，G1了解哪些區(qū)域幾乎是空的，然后優(yōu)先收集這些區(qū)域，這就是GarbageFirst的命名由來。G1將垃圾收集和內(nèi)存整理活動專注于那些幾乎全是垃圾的區(qū)域，并建立停頓預(yù)測模型來決定每次GC時回收哪些區(qū)域，以滿足用戶設(shè)定的停頓時間。

對于區(qū)域的回收通過復(fù)制算法實現(xiàn)。在完成標(biāo)記清理后，G1將這幾個區(qū)域的存活對象復(fù)制到一個單獨區(qū)域中，實現(xiàn)內(nèi)存整理和空間釋放。這一過程通過多線程并行進行來降低停頓時間，提高吞吐量。通過這樣的方式，G1在每次GC過程中持續(xù)清理碎片，控制停頓時間滿足用戶要求。這時過去虛擬機無法做到的。CMS不清理內(nèi)存碎片（除非通過虛擬機參數(shù)設(shè)置，在每次或多次FullGC后進行整理），ParallelOld進行全堆整理，會導(dǎo)致較長的停頓時間。

G1不是實時垃圾收集器，它會盡量讓停頓時間低于用戶設(shè)置的停頓時間目標(biāo)但不能保證一定如此。G1根據(jù)歷史垃圾收集監(jiān)測數(shù)據(jù)來 預(yù)測每個區(qū)域的回收時間，然后根據(jù)用戶設(shè)定的目標(biāo)停頓時間決定每次GC時可以回收哪些區(qū)域。G1通過這種方式建立比較精確的區(qū)域回收時間預(yù)測模型。

注意：G1有并發(fā)階段（與應(yīng)用線程并行，無停頓時間）和并行階段（多線程，應(yīng)用工作線程停頓）。FullGC仍是單線程，但如果調(diào)優(yōu)合適，F(xiàn)ullGC是可以避免的。

G1 Footprint

內(nèi)存占用

如果從ParallelOldGC或CMS遷移至G1，你會發(fā)現(xiàn)JVM線程占用內(nèi)存增大。增大的部分主要與'accouting'數(shù)據(jù)結(jié)構(gòu)有關(guān)，如Remembered Sets(RSets)和Collection Sets(CSets)。

• Remembered Sets RSets跟蹤指向某個區(qū)域的對象引用。每個區(qū)域?qū)?yīng)一個RSet。RSets對整體內(nèi)存占用的影響少于5%。

• Collection Sets CSets 在一次GC中將被回收的區(qū)域集合。所有CSet區(qū)域中的存活對象都會被移動到新的區(qū)域中，這些區(qū)域可以是Eden區(qū)、survivor區(qū)或老年代。CSets對JVM內(nèi)存占用影響少于1%。

Recommended Use Cases for G1

G1的推薦使用場景

G1的設(shè)計初衷是為用戶提供大內(nèi)存、低GC停頓時間的應(yīng)用解決方案。這意味著堆內(nèi)存6G或更大，停頓時間穩(wěn)定且少于0.5秒。

如果應(yīng)用正在使用CMS或ParallelOld且面臨以下問題，推薦將應(yīng)用遷移至G1

• FullGC發(fā)生頻繁或總時間過長
• 對象分配率或?qū)ο笊壷晾夏甏谋壤▌虞^大
• 較長的垃圾收集或內(nèi)存整理停頓（大于0.5至1秒）

注意：如果應(yīng)用沒有上述問題，不需要遷移虛擬機。G1并不是最新JDK要求的虛擬機。

Reviewing Generational GC and CMS

回顧分代GC和CMS

CMS（并發(fā)低停頓收集器）收集老年代。通過將大部分垃圾回收工作與應(yīng)用線程并發(fā)進行，盡可能降低停頓時間。通常CMS不回去復(fù)制和整理內(nèi)存。GC過程不會移動對象。如果內(nèi)存碎片問題嚴(yán)重，擴充堆內(nèi)存。

CMS Collection Phases

CMS回收步驟

CMS在老年代上回收步驟如下：

Heap Structure for CMS Collector

CMS收集器堆內(nèi)存結(jié)構(gòu)

堆內(nèi)存被分配為三部分。

新生代分為Eden區(qū)和兩個survivor區(qū)。老年代是一塊連續(xù)區(qū)域。只有FullGC時才可能發(fā)生內(nèi)存整理。

How Young GC works in CMS

CMS中的新生代GC

新生代淡綠色，老年代藍色。系統(tǒng)運行一段時間后CMS堆內(nèi)存可能如下圖所示，對象分散在老年代各處。

老年代對象空間原地回收，CMS不會移動它們。內(nèi)存整理只會發(fā)生在FullGC時。

Young Generation Collection

新生代回收

新生代存活對象從Eden區(qū)和survivor區(qū)復(fù)制到另一個空閑的survivor區(qū)。任何minorGC年齡達到閾值的老對象被升級至老年代。

After Young GC

新生代GC后

youngGC（minorGC）后，Eden區(qū)和一個survivor區(qū)被清空。

新近升級至老年代的對象以深藍色表示。綠色對象是新生代仍存活的對象。

Old Generation Collection with CMS

CMS老年代垃圾回收

在初始標(biāo)記和重新標(biāo)記階段發(fā)生STW。當(dāng)老年代剩余空間達到閾值時（發(fā)生Concurrent Mode Failure），使用SerialOld替代CMS進行老年代GC。

(1)初始標(biāo)記停頓時間很短，簡單的標(biāo)記GCRoot引用的對象。(2)并發(fā)標(biāo)記在標(biāo)記存活對象時，應(yīng)用繼續(xù)執(zhí)行。(3)重新標(biāo)記階段，標(biāo)記并發(fā)階段遺漏的存活對象。

Old Generation Collection - Concurrent Sweep

老年代垃圾收集-并發(fā)清除

未被標(biāo)記的對象直接被回收，不會發(fā)生內(nèi)存整理。

Old Generation Collection - After Sweeping

老年代垃圾收集-清掃后

完成并發(fā)清掃后，許多老年代空間被釋放出來。同時內(nèi)存整理仍沒有發(fā)生，老年代存在大量內(nèi)存碎片。

最終，CMS經(jīng)過重置階段，等待下一次GC。

The G1 Garbage Collector Step by Step

G1垃圾收集步驟

G1 Heap Structure

G1堆內(nèi)存結(jié)構(gòu)

G1的堆內(nèi)存被分成許多固定大小的區(qū)域。

區(qū)域大小相同，在JVM啟動時確定。JVM通常管理2000個區(qū)域，區(qū)域大小介于1M到32M之間。

G1 Heap Allocation

G1堆內(nèi)存分配

這些區(qū)域被映射為邏輯上的Eden、survivor和老年代區(qū)域，相同類型區(qū)域地址可以不連續(xù)。

區(qū)域分為五種，Eden、survivor和老年代，另外還有一種大對象區(qū)，這些區(qū)域用來存放占據(jù)50%以上區(qū)域空間的對象，這些對象被存儲在一組連續(xù)區(qū)域內(nèi)，最后一種區(qū)域就是未被使用區(qū)域。

G1不要求區(qū)域連續(xù)。

A Young GC in G1

G1的新生代GC

存活對象移動到一個或多個survivor區(qū)域。如果對象達到晉升年齡，將被移動到老年代區(qū)域。

這一階段包括STW。eden區(qū)和survivor區(qū)大小重新計算為下一次youngGC做準(zhǔn)備。這一過程使得動態(tài)調(diào)整各區(qū)大小非常簡單。

End of a Young GC with G1

G1的youngGC結(jié)束

存活對象被移動到survivor區(qū)或老年代區(qū)域。

G1新生代有如下總結(jié)：

• 堆內(nèi)存是一個單獨的內(nèi)存區(qū)域，被分為多個大小相同的區(qū)域
• 新生代內(nèi)存由一系列不連續(xù)的區(qū)域組成。按需調(diào)整內(nèi)存大小很簡單。
• 新生代垃圾回收（youngGC）需要STW，所有應(yīng)用線程需要停頓。
• youngGC多線程并行執(zhí)行。
• 存活對象復(fù)制到新的survivor區(qū)或老年代區(qū)。

Old Generation Collection with G1

G1老年代垃圾回收

G1 Collection Phases - Concurrent Marking Cycle Phases

G1回收階段-并發(fā)標(biāo)記周期階段

G1回收器在對內(nèi)存的老年代區(qū)域執(zhí)行以下階段。注意這些階段也包括新生代的回收。

G1 Old Generation Collection Step by Step

G1老年代回收步驟

Initial Marking Phase

初始標(biāo)記階段

新生代垃圾收集捎帶著一次存活對象的初始標(biāo)記。在GC日志中打印為GCpause(young)(inital-mark)

Concurrent Marking Phase

并發(fā)標(biāo)記階段

此階段如果發(fā)現(xiàn)空區(qū)域，將會在再次標(biāo)記階段立即回收。同時，計算各區(qū)域活躍度（回收優(yōu)先級）的所需的信息在這個階段統(tǒng)計。

Remark Phase

再次標(biāo)記階段

這一階段空區(qū)域被回收，計算出所有區(qū)域活躍度。

Copying/Cleanup Phase

復(fù)制/清理階段

G1選擇那些活躍度最低，回收速度最快的區(qū)域進行回收。這些區(qū)域回收的同時進行youngGC。GC日志中記錄為[GC pause (mixed)]。因此新生代和老年代垃圾回收同時發(fā)生。

After Copying/Cleanup Phase

復(fù)制/清理階段后

被選中區(qū)域的存活對象移動到新的區(qū)域中，原區(qū)域被回收加入空白列表。

Summary of Old Generation GC

老年代GC總結(jié)

• 并發(fā)標(biāo)記階段
• 區(qū)域活躍度信息的統(tǒng)計與應(yīng)用線程并發(fā)進行
• 活躍度信息決定了那個區(qū)域最先在清理階段被回收
• 沒有CMS的清理階段
• 再次標(biāo)記階段
• SATB算法比CMS使用的算法更快
• 空區(qū)域在這個階段被回收
• 復(fù)制/清理階段
• 新生代和老年代同時被回收
• 老年代根據(jù)活躍度確定回收優(yōu)先級

關(guān)于Remembered Set概念：G1收集器中，Region之間的對象引用以及其他收集器中的新生代和老年代之間的對象引用是使用Remembered Set來避免掃描全堆。G1中每個Region都有一個與之對應(yīng)的Remembered Set，虛擬機發(fā)現(xiàn)程序?qū)eference類型數(shù)據(jù)進行寫操作時，會產(chǎn)生一個Write Barrier暫時中斷寫操作，檢查Reference引用的對象是否處于不同的Region之間(在分代中例子中就是檢查是否老年代中的對象引用了新生代的對象)，如果是便通過CardTable把相關(guān)引用信息記錄到被引用對象所屬的Region的Remembered Set中。當(dāng)內(nèi)存回收時，在GC根節(jié)點的枚舉范圍加入Remembered Set即可保證不對全局堆掃描也不會有遺漏。

Command Line Options and Best Practices

JVM參數(shù)最佳實踐

Basic Command Line

基本命令

啟用G1 -XX:+UserG1GC
以下是使用G1收集器的javademo演示
java -Xmx50m -Xms50m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar c:\javademos\demo\jfc\Java2D\Java2demo.jar

Key Command Line Switches

關(guān)鍵命令

• -XX:+UseG1GC - 啟用G1
• -XX:MaxGCPauseMillis=200 - GC停頓的最長時間。這是一個軟目標(biāo)，即虛擬機會盡最大可能滿足這一時間，但某些情況下仍可能超過。默認(rèn)值為200ms。
• -XX:InitiatingHeapOccupancyPercent=45 - 堆內(nèi)存使用率達到多少時啟動一次GC過程。GC過程涉及整個堆內(nèi)存，不單指某個年齡代。設(shè)為0時表示循環(huán)進行并發(fā)GC。默認(rèn)值為45，即堆內(nèi)存使用45%后觸發(fā)一次GC。

Best Practices

最佳實踐

Do not Set Young Generation Size

不要設(shè)置新生代大小

設(shè)置新生代大小-Xmn會影響G1的回收表現(xiàn)。

• G1不在遵守目標(biāo)停頓時間，即設(shè)置新生代大小后，目標(biāo)停頓時間失效。
• G1不能按需擴展或收縮新生代空間。

Response Time Metrics

響應(yīng)時間指標(biāo)

不要根據(jù)平均響應(yīng)時間ART設(shè)置MaxGCPauseMillis參數(shù)，將這個值設(shè)置為90%的用戶發(fā)起請求時的等待時間不會超過的值。

What is an Evacuation Failure?

轉(zhuǎn)移失敗

在GC過程中，堆內(nèi)存區(qū)域耗盡，新生代對象晉升老年代失敗。堆內(nèi)存由于已經(jīng)達到最大而無法擴張。在GClog中打印to-space overflow日志。這會耗費大量資源。

• GC仍要繼續(xù)，所以空間必須被釋放。
• 拷貝失敗的對象必須留在原區(qū)域。
• 這一過程中，CSets中區(qū)域的RSets如果發(fā)生變化，RSets需要重新生成。
• 這些步驟都非常耗費資源。

How to avoid Evacuation Failure

如何避免轉(zhuǎn)移失敗

• 增加堆內(nèi)存大小
• 提高-XX:G1ReservePercent，默認(rèn)值是10
• G1為堆內(nèi)存設(shè)置虛擬使用上限，預(yù)留一部分空間防止to-space情況出現(xiàn)
• 提前進行標(biāo)記階段
• 提高標(biāo)記階段的線程數(shù)，-XX:ConcGCThreads

Complete List of G1 GC Switches

G1 GC參數(shù)一覽

Logging GC with G1

G1的GC日志

Setting the Log Detail
You can set the detail to three different levels of detail.
(1) -verbosegc (which is equivalent to -XX:+PrintGC) sets the detail level of the log to fine.
Sample Output
[GC pause (G1 Humongous Allocation) (young) (initial-mark) 24M- >21M(64M), 0.2349730 secs][GC pause (G1 Evacuation Pause) (mixed) 66M->21M(236M), 0.1625268 secs]
(2) -XX:+PrintGCDetails sets the detail level to finer. The options shows the following information:
Average, Min, and Max time are displayed for each phase.
Root Scan, RSet Updating (with processed buffers information), RSet Scan, Object Copy, Termination (with number of attempts).
Also shows “other” time such as time spent choosing CSet, reference processing, reference enqueuing and freeing CSet.
Shows the Eden, Survivors and Total Heap occupancies.

Sample Output
[Ext Root Scanning (ms): Avg: 1.7 Min: 0.0 Max: 3.7 Diff: 3.7][Eden: 818M(818M)->0B(714M) Survivors: 0B->104M Heap: 836M(4096M)->409M(4096M)]
(3) -XX:+UnlockExperimentalVMOptions -XX:G1LogLevel=finest sets the detail level to its finest. Like finer but includes individual worker thread information.
[Ext Root Scanning (ms): 2.1 2.4 2.0 0.0 Avg: 1.6 Min: 0.0 Max: 2.4 Diff: 2.3] [Update RS (ms): 0.4 0.2 0.4 0.0 Avg: 0.2 Min: 0.0 Max: 0.4 Diff: 0.4] [Processed Buffers : 5 1 10 0 Sum: 16, Avg: 4, Min: 0, Max: 10, Diff: 10]
Determining Time
A couple of switches determine how time is displayed in the GC log.
(1) -XX:+PrintGCTimeStamps - Shows the elapsed time since the JVM started.
Sample Output
1.729: [GC pause (young) 46M->35M(1332M), 0.0310029 secs]
(2) -XX:+PrintGCDateStamps - Adds a time of day prefix to each entry.
2012-05-02T11:16:32.057+0200: [GC pause (young) 46M->35M(1332M), 0.0317225 secs]
Understanding G1 Log
To understand the log, this section defines a number of terms using actual GC log output. The following examples show output from the log with explanations of the terms and values you will find in it.
Note: For more information check out Poonam Bajaj's Blog post on G1 GC logs.
G1 Logging Terms Index
Clear CT
CSet
External Root Scanning
Free CSet
GC Worker End
GC Worker Other
Object Copy
Other
Parallel Time
Ref Eng
Ref Proc
Scanning Remembered Sets
Termination Time
Update Remembered Set
Worker Start
Parallel Time
414.557: [GC pause (young), 0.03039600 secs] [Parallel Time: 22.9 ms][GC Worker Start (ms): 7096.0 7096.0 7096.1 7096.1 706.1 7096.1 7096.1 7096.1 7096.2 7096.2 7096.2 7096.2 Avg: 7096.1, Min: 7096.0, Max: 7096.2, Diff: 0.2]
Parallel Time – Overall elapsed time of the main parallel part of the pause
Worker Start – Timestamp at which the workers start
Note: The logs are ordered on thread id and are consistent on each entry
External Root Scanning
[Ext Root Scanning (ms): 3.1 3.4 3.4 3.0 4.2 2.0 3.6 3.2 3.4 7.7 3.7 4.4 Avg: 3.8, Min: 2.0, Max: 7.7, Diff: 5.7]
External root scanning - The time taken to scan the external root (e.g., things like system dictionary that point into the heap.)
Update Remembered Set
[Update RS (ms): 0.1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 Avg: 0.0, Min: 0.0, Max: 0.1, Diff: 0.1] [Processed Buffers : 26 0 0 0 0 0 0 0 0 0 0 0 Sum: 26, Avg: 2, Min: 0, Max: 26, Diff: 26]
Update Remembered Set - Any buffers that are completed but have not yet been processed by the concurrent refinement thread before the start of the pause have to be updated. Time depends on density of the cards. The more cards, the longer it will take.
Scanning Remembered Sets
[Scan RS (ms): 0.4 0.2 0.1 0.3 0.0 0.0 0.1 0.2 0.0 0.1 0.0 0.0 Avg: 0.1, Min: 0.0, Max: 0.4, Diff: 0.3]F
Scanning Remembered Sets - Look for pointers that point into the Collection Set.
Object Copy
[Object Copy (ms): 16.7 16.7 16.7 16.9 16.0 18.1 16.5 16.8 16.7 12.3 16.4 15.7 Avg: 16.3, Min: 12.3, Max: 18.1, Diff: 5.8]
Object copy – The time that each individual thread spent copying and evacuating objects.
Termination Time
[Termination (ms): 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.00.0 Avg: 0.0, Min: 0.0, Max: 0.0, Diff: 0.0] [Termination Attempts : 1 1 1 1 1 1 1 1 1 1 1 1 Sum: 12, Avg: 1, Min: 1, Max: 1, Diff: 0]
Termination time - When a worker thread is finished with its particular set of objects to copy and scan, it enters the termination protocol. It looks for work to steal and once it's done with that work it again enters the termination protocol. Termination attempt counts all the attempts to steal work.
GC Worker End
[GC Worker End (ms): 7116.4 7116.3 7116.4 7116.3 7116.4 7116.3 7116.4 7116.4 7116.4 7116.4 7116.3 7116.3 Avg: 7116.4, Min: 7116.3, Max: 7116.4, Diff: 0.1][GC Worker (ms): 20.4 20.3 20.3 20.2 20.3 20.2 20.2 20.2 20.3 20.2 20.1 20.1 Avg: 20.2, Min: 20.1, Max: 20.4, Diff: 0.3]
GC worker end time – Timestamp when the individual GC worker stops.
GC worker time – Time taken by individual GC worker thread.
GC Worker Other
[GC Worker Other (ms): 2.6 2.6 2.7 2.7 2.7 2.7 2.7 2.8 2.8 2.8 2.8 2.8 Avg: 2.7, Min: 2.6, Max: 2.8, Diff: 0.2]
GC worker other – The time (for each GC thread) that can't be attributed to the worker phases listed previously. Should be quite low. In the past, we have seen excessively high values and they have been attributed to bottlenecks in other parts of the JVM (e.g., increases in the Code Cache occupancy with Tiered).
Clear CT
[Clear CT: 0.6 ms]
Time taken to clear the card table of RSet scanning meta-data
Other
[Other: 6.8 ms]
Time taken for various other sequential phases of the GC pause.
CSet
[Choose CSet: 0.1 ms]
Time taken finalizing the set of regions to collect. Usually very small; slightly longer when having to select old.
Ref Proc
[Ref Proc: 4.4 ms]
Time spent processing soft, weak, etc. references deferred from the prior phases of the GC.
Ref Enq
[Ref Enq: 0.1 ms]
Time spent placing soft, weak, etc. references on to the pending list.
Free CSet
[Free CSet: 2.0 ms]
Time spent freeing the set of regions that have just been collected, including their remembered sets.