目錄

1、暢想GC的目標(biāo)

2、jvm調(diào)優(yōu)的目標(biāo)

3、GC調(diào)優(yōu)時(shí)機(jī)

4、垃圾收集器的選擇

5、G1調(diào)優(yōu)策略

6、G1垃圾收集實(shí)踐

6.1、JVM自動(dòng)選擇垃圾收集器

6.2、G1垃圾收集

6.3、GC日志分析

7、小結(jié)

---

前言 c++和java之間有一堵由內(nèi)存動(dòng)態(tài)分配和垃圾收集技術(shù)所圍成的墻，墻外面的人想進(jìn)去墻里面的人想出來(lái)。

1、暢想GC的目標(biāo)

? ? 詹姆斯·高斯林?（James Gosling）是一名軟件專家，喊出了口號(hào)：“一次編寫，到處亂跑。” 他在1995年寫java這門編程語(yǔ)言的時(shí)候，可能并沒(méi)有想到j(luò)ava會(huì)如此廣泛的應(yīng)用于web開(kāi)發(fā)，沒(méi)有意識(shí)到要進(jìn)行更多的web交互場(chǎng)景，應(yīng)用對(duì)停頓時(shí)間要求是如此的嚴(yán)格，否則在剛開(kāi)始設(shè)計(jì)垃圾回收的時(shí)候就不會(huì)粗暴的直接將應(yīng)用線程停掉了。這個(gè)在現(xiàn)在來(lái)看是不太能接受的，隨著jdk往上發(fā)展，web的高并發(fā)，交互場(chǎng)景的越來(lái)越頻繁，所以要追求低停頓和高吞吐量成了程序員們的追求，所以垃圾收集器就需要與時(shí)俱進(jìn)的進(jìn)行不斷的優(yōu)化，再優(yōu)化，直到?jīng)]有停頓。 以至于出現(xiàn)了Z-GC，Z也不知道是不是zero的意思，代表著程序員們的極致追求，沒(méi)有停頓時(shí)間。 The Z Garbage Collector (ZGC) is a scalable low latency garbage collector. ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than 10ms, which makes is suitable for applications which require low latency and/or use a very large heap (multi-terabytes). The Z Garbage Collector is available as an experimental feature, and is enabled with the command-line options-XX:+UnlockExperimentalVMOptions -XX:+UseZGC.

ZGC的官網(wǎng)描述：Z-GC目標(biāo)：能夠讓應(yīng)用gc停頓的時(shí)間低于：10ms，適用于更大堆。

參考資料：Z-Gabage:https://docs.oracle.com/en/java/javase/11/gctuning/z-garbage-collector1.html#GUID-A5A42691-095E-47BA-B6DC-FB4E5FAA43D0

2、jvm調(diào)優(yōu)的目標(biāo)

隨著互聯(lián)網(wǎng)的web應(yīng)用流量激增，堆內(nèi)存空間的不斷增大，從官方垃圾收集器的一步步優(yōu)化之路不難發(fā)現(xiàn)，程序員對(duì)JVM 的垃圾收集追求的目標(biāo)在于以下三點(diǎn)：

• 吞吐量-Throughput；運(yùn)行用戶代碼時(shí)間/(運(yùn)行用戶代碼時(shí)間+垃圾收集時(shí)間)
• 停頓時(shí)間-PauseTime；垃圾收集器進(jìn)行 垃圾回收中斷應(yīng)用執(zhí)行響應(yīng)的時(shí)間
• GC的頻率-GCTimes；一般不做硬性要求，能接受一定程度的younggc，但一定要避免full-gc；

停頓時(shí)間越短就越適合需要和用戶交互的程序，良好的響應(yīng)速度能提升用戶體驗(yàn); 高吞吐量則可以高效地利用CPU時(shí)間，盡快完成程序的運(yùn)算任務(wù)，主要適合在后臺(tái)運(yùn)算而不需要太多交互的任務(wù)。 吞吐量和停頓時(shí)間也是評(píng)價(jià)一個(gè)垃圾收集器優(yōu)劣的指標(biāo)。 可能JVM對(duì)垃圾收集器追求的終極目標(biāo)是：沒(méi)有停頓時(shí)間且擁有高吞吐量。 遺憾的是，目前還沒(méi)有這樣一款垃圾收集器問(wèn)世，當(dāng)然，也不是所有的應(yīng)用都是追求停頓時(shí)間，可能有的不在乎時(shí)間而在乎吞吐量，所以我們目前所能做到的就是不斷調(diào)優(yōu)，根據(jù)業(yè)務(wù)場(chǎng)景找到適應(yīng)各自的項(xiàng)目需求的垃圾收集器，讓上面的三個(gè)主要的目標(biāo)達(dá)到最優(yōu)。

3、GC調(diào)優(yōu)時(shí)機(jī)

什么時(shí)候才需要調(diào)優(yōu)？GC到底影響什么？GC的常見(jiàn)癥狀？ 首先一定不是無(wú)聊，天馬行空的改參數(shù)，那樣反而適得其反。 例如GC停頓導(dǎo)致常見(jiàn)的問(wèn)題的癥狀：

• 系統(tǒng)CPU飆升很快;
  • 系統(tǒng)運(yùn)行的響應(yīng)時(shí)間長(zhǎng)，接口響應(yīng)超時(shí);
  • 網(wǎng)站經(jīng)常不定期出現(xiàn)：長(zhǎng)時(shí)間沒(méi)有響應(yīng)的現(xiàn)象。
  • gc次數(shù)太多，用戶線程代碼執(zhí)行受影響，cpu使用會(huì)高？
• 內(nèi)存的使用率逐漸增大，不夠用了；

4、垃圾收集器的選擇

jvm調(diào)優(yōu)：如何調(diào)優(yōu)才能實(shí)現(xiàn)我們的目標(biāo)呢，首先是垃圾收集器的選擇。 首先要明確，jvm的調(diào)優(yōu)沒(méi)有萬(wàn)能公式，每個(gè)項(xiàng)目背景和要求不同，調(diào)優(yōu)的策略和參數(shù)都不一樣。 首先關(guān)于垃圾收集器的選擇：并不是并發(fā)度越高就越好的，停頓時(shí)間越短就越好。需要根據(jù)具體的情況來(lái)看。 官網(wǎng)垃圾收集器的選擇標(biāo)準(zhǔn)：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html#sthref28 Selecting a Collector 首先讓jvm來(lái)自動(dòng)選擇，不能滿足； 調(diào)整堆的大小，減少垃圾回收次數(shù)； Unless your application has rather strict pause time requirements, first run your application and allow the VM to select a collector. If necessary, adjust the heap size to improve performance.? 如果仍然不能滿足： If the performance still does not meet your goals, then use the following guidelines as a starting point for selecting a collector.內(nèi)存小于100m，可以選擇serial收集器； * If the application has a small data set (up to approximately 100 MB), then select the serial collector with the option? -XX:+UseSerialGC.單線程，使用serial； * If the application will be run on a single processor and there are no pause time requirements, then let the VM select the collector, or select the serial collector with the option-XX:+UseSerialGC.沒(méi)有停頓時(shí)間的要求，關(guān)注吞吐量，選擇并行收集器； * If (a) peak application performance is the first priority and (b) there are no pause time requirements or pauses of 1 second or longer are acceptable, then let the VM select the collector, or select the parallel collector with-XX:+UseParallelGC.關(guān)注停頓時(shí)間的要求，可以選擇G1; * If response time is more important than overall throughput and garbage collection pauses must be kept shorter than approximately 1 second, then select the concurrent collector with -XX:+UseConcMarkSweepGC or-XX:+UseG1GC.

根據(jù)官網(wǎng)推薦，垃圾收集器的選擇標(biāo)準(zhǔn)總結(jié)如下：

優(yōu)先調(diào)整堆的大小讓服務(wù)器jvm自己來(lái)選擇一個(gè)合適的垃圾收集器；

如果內(nèi)存小于100M，使用串行收集器；

如果是單核，并且沒(méi)有停頓時(shí)間要求，使用串行或JVM自己選

如果允許停頓時(shí)間超過(guò)1秒，選擇并行CMS或JVM自己選;

如果響應(yīng)時(shí)間最重要，并且不能超過(guò)1秒，使用并發(fā)收集器G1;

從結(jié)論可以看出：選擇一個(gè)合適的垃圾收集需要根據(jù)系統(tǒng)的要求：

• 比如cpu的核心數(shù)：如果是單核cpu，選擇并發(fā)垃圾收集器也沒(méi)有用，因?yàn)閱魏诉€是串行的，線程的切換反而降低了垃圾收集的效率；
• 堆的大小：類似G1垃圾收集，它的內(nèi)存布局讓它更適合大堆內(nèi)存的收集，而小堆內(nèi)存串行和CMS就能有比較高的性能；
• 是否關(guān)注停頓時(shí)間：如果不關(guān)注停頓時(shí)間關(guān)注吞吐量，串行和CMS就能提供很好的性能，也并不是G1就是最好的；

5、G1調(diào)優(yōu)策略

官方也給出了G1調(diào)優(yōu)的一些建議指南：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html#recommendations

• (1)不要手動(dòng)設(shè)置新生代和老年代的大小，只要設(shè)置整個(gè)堆的大小
  • G1收集器在運(yùn)行過(guò)程中，會(huì)自己調(diào)整新生代和老年代的大小 其實(shí)是通過(guò)自動(dòng)調(diào)整young代的大小來(lái)調(diào)整對(duì)象晉升的速度，從而達(dá)到為收集器設(shè)置的暫停時(shí)間目標(biāo)，如果手動(dòng)設(shè)置了大小就意味著放棄了G1的自動(dòng)調(diào)優(yōu)，破壞了停頓時(shí)間策略；
• (2) 不斷調(diào)優(yōu)暫停時(shí)間；不要太嚴(yán)格
  • 一般情況下這個(gè)值設(shè)置到100ms或者200ms都是可以的(不同情況下會(huì)不一樣)，但如果設(shè)置成50ms就不太合理。
  • 暫停時(shí)間設(shè)置的太短，就會(huì)導(dǎo)致出現(xiàn)G1跟不上垃圾產(chǎn)生的速度。最終退化成Full GC。
  • 所以對(duì)這個(gè)參數(shù)的調(diào)優(yōu)是一個(gè)持續(xù) 的過(guò)程，逐步調(diào)整到最佳狀態(tài)。暫停時(shí)間只是一個(gè)目標(biāo)，并不能總是得到滿足。
• (3)使用-XX:ConcGCThreads=n來(lái)增加標(biāo)記線程的數(shù)量
  • IHOP如果閥值設(shè)置過(guò)高，可能會(huì)遇到轉(zhuǎn)移失敗的風(fēng)險(xiǎn)，比如對(duì)象進(jìn)行轉(zhuǎn)移時(shí)空間不足。如果閥值設(shè)置過(guò)低，就會(huì)使標(biāo) 記周期運(yùn)行過(guò)于頻繁，并且有可能混合收集期回收不到空間。 IHOP值如果設(shè)置合理，但是在并發(fā)周期時(shí)間過(guò)長(zhǎng)時(shí)，可以嘗試增加并發(fā)線程數(shù)，調(diào)高ConcGCThreads。
• (4)MixedGC調(diào)優(yōu)
  • -XX:InitiatingHeapOccupancyPercent=45?：觸發(fā)并發(fā)標(biāo)記的堆內(nèi)存使用占比；
  • -XX:G1MixedGCLiveThresholdPercent
  • -XX:G1MixedGCCountTarger
  • -XX:G1OldCSetRegionThresholdPercent
• (5)條件允許的情況下，適當(dāng)增加堆內(nèi)存大小

6、G1垃圾收集實(shí)踐

一般如果發(fā)現(xiàn)gc頻繁，或者gc停頓時(shí)間長(zhǎng)不可接受，我們就需要對(duì)gc的參數(shù)進(jìn)行調(diào)整，然后通過(guò)日志，調(diào)整參數(shù)，達(dá)到一個(gè)GC停頓時(shí)間和吞吐量的最佳的狀態(tài)，我們將用以下代碼來(lái)模擬查看堆區(qū)的gc日志來(lái)進(jìn)一步了解jvm各垃圾收集的工作過(guò)程，由于CMS之前分析過(guò)，這里不在贅述，主要分析下G1收集器。

6.1、JVM自動(dòng)選擇垃圾收集器

首先我們自己不設(shè)置垃圾收集器，讓JVM自己來(lái)為我們選擇，因?yàn)楣俜酵扑]這么做，當(dāng)不知道如何選擇的時(shí)候可以把這個(gè)權(quán)限交給JVM，JVM會(huì)默認(rèn)的選擇一個(gè)垃圾回收器，用下面一小段代碼來(lái)不斷產(chǎn)生垃圾，看垃圾收集器的作用及日志。 public class HeapOomGCTest {public static String heapOOMtest() throws InterruptedException {List<Person> list = new ArrayList<Person>();while (true) {list.add(new Person());System.out.println("add Person success~");Thread.sleep(10);}}public static void main(String[] args) throws InterruptedException {heapOOMtest();} }

設(shè)置參數(shù)如下：

-Xms30m -Xmx30m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:JvmAutoSelectGC.log

JvmAutoSelectGC.log日志解讀： Java HotSpot(TM) 64-Bit Server VM (25.201-b09) for bsd-amd64 JRE (1.8.0_201-b09), built on Dec 15 2018 18:35:23 by "java_re" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Memory: 4k page, physical 16777216k(651656k free)/proc/meminfo:CommandLine flags: -XX:InitialHeapSize=31457280 -XX:MaxHeapSize=31457280 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC2020-11-22T09:05:50.054-0800: 10.188: [GC (Allocation Failure) [PSYoungGen: 8192K->1008K(9216K)] 8192K->1276K(29696K),0.0019565 secs] [Times: user=0.00 sys=0.01, real=0.00 secs]

日志具體內(nèi)容分析：

-XX:+UseParallelGC :通過(guò)日志發(fā)現(xiàn)在沒(méi)有設(shè)置GC垃圾收集器的情況下，JDK1.8默認(rèn)使用的垃圾收集器：ParallerGC = ParallerScavge +?ParallerOld GC：表明進(jìn)行了一次垃圾回收，前面沒(méi)有Full修飾，PSYoungGen表明這是一次新生代的Minor GC，這里不管是新生代還是老年代都會(huì)STW。 Allocation Failure：表明本次引起GC的原因是因?yàn)樵谀贻p代中沒(méi)有足夠的空間能夠存儲(chǔ)新的數(shù)據(jù)了。 8192K->1008K(9216K)：(單位是KB)三個(gè)參數(shù)分別為：GC前該內(nèi)存區(qū)域(這里是年輕代)使用容量，GC后該內(nèi)存區(qū)域使用容量，該內(nèi)存區(qū)域總?cè)萘俊?因?yàn)槲以O(shè)置的總堆大小為30M=30720kb,-XX:NewRatio=2，出去其他的內(nèi)存占用，所以新生代Eden區(qū)的總?cè)萘繛?#xff1a;9216kb 0.0019565 secs：該內(nèi)存區(qū)域GC耗時(shí)，單位是秒 8192K->1276K(29696K)：三個(gè)參數(shù)分別為：堆區(qū)垃圾回收前的大小，堆區(qū)垃圾回收后的大小，堆區(qū)總大小。 [Times: user=0.00 sys=0.01, real=0.00 secs]：分別表示用戶態(tài)耗時(shí)，內(nèi)核態(tài)耗時(shí)和總耗時(shí)

6.2、G1垃圾收集

參數(shù)設(shè)置如下： -Xms500m -Xmx500m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+UseG1GC -XX:MaxGCPauseMillis=15 -Xloggc:G1-gc.log

CommandLine flags: -XX:CMSInitiatingOccupancyFraction=30 -XX:InitialHeapSize=5242880 -XX:MaxHeapSize=5242880 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC #使用 G1垃圾收集； # 什么時(shí)候發(fā)生的GC，相對(duì)的時(shí)間刻，GC發(fā)生的區(qū)域young，總共花費(fèi)的時(shí)間，0.00478s， 2020-11-22T13:45:42.218-0800: 0.196: [GC pause (G1 Evacuation Pause) (young), 0.0018535 secs]# 表示8個(gè)垃圾回收線程，并行的時(shí)間[Parallel Time: 1.2 ms, GC Workers: 8]# GC線程開(kāi)始相對(duì)于上面的0.196的時(shí)間刻[GC Worker Start (ms): Min: 122.3, Avg: 122.5, Max: 123.0, Diff: 0.7][Ext Root Scanning (ms): Min: 0.0, Avg: 0.2, Max: 0.9, Diff: 0.9, Sum: 1.9][Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0][Processed Buffers: Min: 0, Avg: 0.0, Max: 0, Diff: 0, Sum: 0][Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0][Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0][Object Copy (ms): Min: 0.0, Avg: 0.2, Max: 0.4, Diff: 0.4, Sum: 1.8][Termination (ms): Min: 0.0, Avg: 0.4, Max: 0.5, Diff: 0.5, Sum: 3.0][Termination Attempts: Min: 1, Avg: 1.8, Max: 4, Diff: 3, Sum: 14][GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1][GC Worker Total (ms): Min: 0.3, Avg: 0.8, Max: 1.1, Diff: 0.8, Sum: 6.8][GC Worker End (ms): Min: 123.3, Avg: 123.4, Max: 123.5, Diff: 0.1][Code Root Fixup: 0.0 ms][Code Root Purge: 0.0 ms][Clear CT: 0.1 ms][Other: 0.5 ms][Choose CSet: 0.0 ms][Ref Proc: 0.3 ms][Ref Enq: 0.0 ms][Redirty Cards: 0.2 ms][Humongous Register: 0.0 ms][Humongous Reclaim: 0.0 ms][Free CSet: 0.0 ms][Eden: 1024.0K(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->1024.0K Heap: 1024.0K(6144.0K)->536.1K(6144.0K)][Times: user=0.01 sys=0.00, real=0.00 secs] G1-GC.log部分日志截取如下：

從上面的日志來(lái)看，其日志格式復(fù)雜了很多，可以參考G1日志詳細(xì)解讀：https://blogs.oracle.com/poonam/understanding-g1-gc-logs

6.3、GC日志分析

6.3.1、本地工具查看：gc-viewer 使用命令運(yùn)行： java -jar?gcviewer-1.36-SNAPSHOT.jar ?

運(yùn)行這個(gè)工具jar包，打開(kāi)我們剛剛生成的G1-GC.log文件，我們就可以看見(jiàn)jvm調(diào)優(yōu)的幾個(gè)核心指標(biāo)，其實(shí)從工具我們也可以清楚的看到j(luò)vm的gc調(diào)優(yōu)關(guān)注的是什么，調(diào)的是什么，停頓時(shí)間-吞吐量-GC頻率。

?? 可以發(fā)現(xiàn)，通過(guò)此工具清楚的看到 g1發(fā)生gc的詳情，停頓耗時(shí)，gc次數(shù)，吞吐量都一目了然，之前我們的設(shè)置參數(shù)如下，設(shè)置的比較小，這樣效果比較明顯。 -Xms5m -Xmx5m -XX:+PrintGCDetails -XX:CMSInitiatingOccupancyFraction=30???-XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:MaxGCPauseMillis=5 -XX:+UseG1GC??-Xloggc:G1-GC.log

我們發(fā)現(xiàn)其核心指標(biāo)如下：

吞吐量	最小停頓時(shí)間	平均停頓時(shí)間	最大停頓時(shí)間	gc次數(shù)
97.25	0.00048	0.00254	0.00671	13

從這幾個(gè)參數(shù)我們就可以看出停頓時(shí)間，吞吐量和gc的次數(shù)是否符合我們的要求，如果不符合我們可以繼續(xù)調(diào)整參數(shù)。 調(diào)整方案：

如果gc頻次高，我們可以適當(dāng)?shù)脑黾佣褍?nèi)存，這樣可能會(huì)增加gc的停頓時(shí)間；

然后我們可以適當(dāng)?shù)目刂茰p小gc的停頓時(shí)間，但不要太嚴(yán)格；如果頻次還是高；

可以修改觸發(fā)G1垃圾回收的閾值-XX:InitialHeapOccupacyPersent，默認(rèn)是45%，可以適當(dāng)?shù)奶岣?#xff1b;

最終達(dá)到頻次，停頓時(shí)間和吞吐量的一個(gè)最優(yōu)值； 6.3.2、在線工具：GCeasy工具 這個(gè)工具也可以看到gc的詳細(xì)過(guò)程及日志情況，還可以比較不同的垃圾收集器的吞吐量和停頓時(shí)間，非常方便，但是在線的工具需要注意安全性。 官網(wǎng)地址 :https://gceasy.io 打開(kāi)我們剛剛生成的G1-gc.log日志，從官網(wǎng)的顯示也可以看出gc調(diào)優(yōu)的三個(gè)重要指標(biāo)：吞吐量 + 停頓時(shí)間 + gc頻次 從結(jié)果可以清晰的看到j(luò)vm調(diào)優(yōu)的三個(gè)核心指標(biāo)的數(shù)據(jù)，不同工具好像統(tǒng)計(jì)出的有一定的差別，所以我們可以通過(guò)這些工具來(lái)幫助我們更好的分析gc日志。

7、小結(jié)

GC的垃圾收集器的參數(shù)和選擇都不唯一，需要根據(jù)項(xiàng)目的場(chǎng)景及硬件條件作出選擇，適合的就是最好的，沒(méi)有銀彈。

• gc調(diào)優(yōu)核心指標(biāo)
  • 吞吐量 —?throughtput
  • 停頓時(shí)間?—pause time
  • gc頻率?— gc times
• GC日志查看工具：
  • GCeasy:在線工具；
  • GCviewer:本地工具；java -jar gc-viewer.jar

OK---望著大河彎彎，終于敢放膽，嬉皮笑臉面對(duì)，人生的難。 水滴石穿，積少成多。學(xué)習(xí)筆記，內(nèi)容簡(jiǎn)單，用于復(fù)習(xí)，梳理鞏固。 參考資料： 《深入理解jvm虛擬機(jī)》 Z-Gabage:https://docs.oracle.com/en/java/javase/11/gctuning/z-garbage-collector1.html#GUID-A5A42691-095E-47BA-B6DC-FB4E5FAA43D0 G1日志詳細(xì)解讀：https://blogs.oracle.com/poonam/understanding-g1-gc-logs G1調(diào)優(yōu)的一些建議指南：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html#recommendations

總結(jié)

以上是生活随笔為你收集整理的G1调优分析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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