柚子快報(bào)激活碼778899分享：JVM 常見配置參數(shù)

http://yzkb.51969.com/

JVM 配置常見參數(shù) Java虛擬機(jī)的參數(shù)，在啟動jar包的時(shí)候通過java 命令指定JVM參數(shù)

-options表示Java虛擬機(jī)的啟動參數(shù)，class為帶有main()函數(shù)的Java類，args表示傳遞給主函數(shù)main()的參數(shù)。

一、系統(tǒng)查看參數(shù):

-XX:+PrintVMOptions可以在程序運(yùn)行時(shí)打印虛擬機(jī)接收到 -XX:+PrintCommandLineFlags可以打印傳遞給虛擬機(jī)的顯式和隱式參數(shù),打印出包括配置文件在內(nèi)的配置 -XX:+PrintFlagsFinal，它會打印所有的系統(tǒng)參數(shù)的值 java -XX:+PrintCommandLineFlags -version

-XX:+PrintFlagsFinal，打印JVM所有參數(shù)的值 -XX:+PrintGC，打印GC信息 -XX:+PrintGCDetails，打印GC詳細(xì)信息 -XX:+PrintGCTimeStamps，打印GC的時(shí)間戳 -Xloggc:filename，設(shè)置GC log文件的位置 -XX:+PrintHeapAtGC查看 GC 前后的堆、方法區(qū)可用容量變化 -XX:+PrintTenuringDistribution，查看熬過收集后剩余對象的年齡分布信息 -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime 查看 GC 過程中用戶線程并發(fā)時(shí)間以及停頓的時(shí)間

1.1.1 查看當(dāng)前系統(tǒng)的垃圾回收器使用的是哪種

jinfo -flags [進(jìn)程pid]

找到-useXXXX這樣的參數(shù)，參數(shù)后即為所使用的GC回收器

[xxx@localhost vpdm]$ jinfo -flags 17049

Attaching to process ID 17049, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 25.341-b10

Non-default VM flags: -XX:CICompilerCount=4 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=null -XX:InitialHeapSize=805306368 -XX:MaxHeapSize=805306368 -XX:MaxNewSize=268435456 -XX:MinHeapDeltaBytes=524288 -XX:NewSize=268435456 -XX:OldSize=536870912 -XX:+PrintFlagsFinal -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseParallelGC

Command line: -Xms768m -Xmx768m -XX:+PrintFlagsFinal -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dumplog/dumplog.log

1.1 堆的配置參數(shù)

-Xms -Xmx 設(shè)置初始堆和最大堆內(nèi)存 -Xmn 設(shè)置新生代內(nèi)存大小 -XX:NewRatio ?？梢栽O(shè)置老年代與新生代的比例。設(shè)置一個(gè)較大的新生代會減小老年代的大小，這個(gè)參數(shù)對系統(tǒng)性能及GC行為有很大的影響。新生代的大小一般設(shè)置為整個(gè)堆空間的1/3到1/4。默認(rèn)值為設(shè)置老年代和新生代內(nèi)存占比，默認(rèn)值為2:1。

默認(rèn)-XX:NewRatio=2新生代占1,老年代占2,年輕代占整個(gè)堆的1/3 假如 -XX:NewRatio=4新生代占1,老年代占4,年輕代占整個(gè)堆的1/5 NewRatio值就是設(shè)置老年代的占比,剩下的1給新生代

-XX:SurvivorRatio用來設(shè)置新生代中eden區(qū)和from/to區(qū)的比例， JVM參數(shù)中有一個(gè)比較重要的參數(shù)SurvivorRatio，它定義了新生代中Eden區(qū)域和Survivor區(qū)域（From幸存區(qū)或To幸存區(qū)）的比例，默認(rèn)值為8:1:1（Eden:From:To），也就是說Eden占新生代的8/10，F(xiàn)rom幸存區(qū)和To幸存區(qū)各占新生代的1/10

-XX:SurvivorRatio 可參考以下計(jì)算公式：

Eden = (R*Y)/(R+1+1)

From = Y/(R+1+1)

To = Y/(R+1+1)

其中： R：SurvivorRatio比例 Y：新生代空間大小

這里舉個(gè)例子，如果我們通過設(shè)置-Xmn60M來指定新生代分配的空間大小，那么Eden則會分配60M * 0.8 = 48M，Survivor一共分配60M * 0.2 = 12M的內(nèi)存空間 啟動參數(shù)配置

-Xmn60M

-XX:SurvivorRatio=8

-XX:+PrintFlagsFinal

控制臺輸出

uintx NewSize := 62914560 {product}

uintx MaxNewSize := 62914560 {product}

它的含義如下

-XX:MaxTenuringThreshold，從年輕代到老年代，最大晉升年齡。CMS 下默認(rèn)為 6，G1 下默認(rèn)為 15

-XX:MaxDirectMemorySize，用于設(shè)置直接內(nèi)存的最大值，限制通過 DirectByteBuffer 申請的內(nèi)存 -XX:ReservedCodeCacheSize，用于設(shè)置 JIT 編譯后的代碼存放區(qū)大小，如果觀察到這個(gè)值有限制，可以適當(dāng)調(diào)大，一般夠用即可

1.2 堆OOM 導(dǎo)出堆的參數(shù)配置

參數(shù)-XX: +HeapDumpOnOutOfMemoryError 配置堆異常時(shí)導(dǎo)出 -XX:HeapDumpPath=./dumplog/dumplog.log 配置都出 堆 dump文件的路徑

nohup java -Xms768m -Xmx768m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dumplog/dumplog.log -jar xxxxxx.jar > logs/xxxxxx.log 2>&1 &

1.3非堆內(nèi)存的參數(shù)配置

nohup java -Xms1g -Xmx1g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dumplog/dumplog.log -Xloggc:./dumplog/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=1500m -XX:MaxMetaspaceExpansion=50M -XX:MinMetaspaceExpansion=10M -XX:CompressedClassSpaceSize=1200m -XX:+TraceClassUnloading -XX:+TraceClassLoading -jar xxxx.jar > logs/xxxx.log 2>&1 &

1.3.1方法區(qū)配置

在JDK 1.6、JDK 1.7中，方法區(qū)可以理解為永久區(qū)（Perm）。在JDK 1.8、JDK1.9、JDK1.10中，永久區(qū)已經(jīng)被徹底移除。取而代之的是元數(shù)據(jù)區(qū)，元數(shù)據(jù)區(qū)大小可以使用參數(shù)-XX:MaxMetaspaceSize指定（一個(gè)大的元數(shù)據(jù)區(qū)可以使系統(tǒng)支持更多的類），這是一塊堆外的直接內(nèi)存

Perm區(qū)域的參數(shù)配置由-XX:MaxMetaspaceSize 替換

-XX:MaxMetaspaceSize指定永久區(qū)的最大可用值 在JDK1.6和JDK1.7等版本中，可以使用-XX:PermSize和-XX:MaxPermSize配置永久區(qū)大小

-XX:MetaspaceSize 參數(shù)的理解

那么-XX:MetaspaceSize=256m的含義到底是什么呢？其實(shí)，這個(gè)JVM參數(shù)是指Metaspace擴(kuò)容時(shí)觸發(fā)FullGC的初始化閾值，也是最小的閾值。這里有幾個(gè)要點(diǎn)需要明確：

如果沒有配置-XX:MetaspaceSize，那么觸發(fā)FGC的閾值是21807104（約20.8m），可以通過jinfo -flag MetaspaceSize pid得到這個(gè)值；

如果配置了-XX:MetaspaceSize，那么觸發(fā)FGC的閾值就是配置的值； Metaspace由于使用不斷擴(kuò)容到-XX:MetaspaceSize參數(shù)指定的量，就會發(fā)生FGC；且之后每次Metaspace擴(kuò)容都可能會發(fā)生FGC（至于什么時(shí)候會，比較復(fù)雜，跟幾個(gè)參數(shù)有關(guān)）； 如果Old區(qū)配置CMS垃圾回收，那么擴(kuò)容引起的FGC也會使用CMS算法進(jìn)行回收；如果MaxMetaspaceSize設(shè)置太小，可能會導(dǎo)致頻繁FullGC，甚至OOM；

任何一個(gè)JVM參數(shù)的默認(rèn)值可以通過java -XX:+PrintFlagsFinal -version |grep JVMParamName獲取，例如：java -XX:+PrintFlagsFinal -version |grep MetaspaceSize

1.3.1.1 查看方法區(qū)的相關(guān)參數(shù)和設(shè)置

[xxx@localhost xxx]$ jps -ml

26732 xxx.jar

[xxx@localhost xxx]$ jinfo -flag CompressedClassSpaceSize 26732

-XX:CompressedClassSpaceSize=528482304

[xxx@localhost xxx]$ jinfo -flag MetaspaceSize 26732

-XX:MetaspaceSize=134217728

[xxx@localhost xxx]$ jinfo -flag MetaspaceSize 26732^C

[xxx@localhost xxx]$ jinfo -flag MaxMetaspaceSize 26732

-XX:MaxMetaspaceSize=536870912

[xxx@localhost xxx]$ jinfo -flag MinMetaspaceFreeRatio 26732

-XX:MinMetaspaceFreeRatio=40

[xxx@localhost xxx]$ jinfo -flag MaxMetaspaceFreeRatio 26732

-XX:MaxMetaspaceFreeRatio=70

[xxx@localhost xxx]$ jinfo -flag CompressedClassSpaceSize 26732

-XX:CompressedClassSpaceSize=528482304

[xxx@localhost xxx]$ jinfo -flag InitialBootClassLoaderMetaspaceSize 26732

-XX:InitialBootClassLoaderMetaspaceSize=4194304

1.3.1.2 查看方法區(qū)的相關(guān)參數(shù)和設(shè)置

Metaspace使用的是本地內(nèi)存，而不是堆內(nèi)存，也就是說在默認(rèn)情況下Metaspace的大小只與本地內(nèi)存大小有關(guān)。當(dāng)然你也可以通過以下的幾個(gè)參數(shù)對Metaspace進(jìn)行控制：

-XX:MetaspaceSize=N 這個(gè)參數(shù)是初始化的Metaspace大小，該值越大觸發(fā)Metaspace GC的時(shí)機(jī)就越晚。隨著GC的到來，虛擬機(jī)會根據(jù)實(shí)際情況調(diào)控Metaspace的大小，可能增加上線也可能降低。在默認(rèn)情況下，這個(gè)值大小根據(jù)不同的平臺在12M到20M浮動。使用java -XX:+PrintFlagsInitial命令查看本機(jī)的初始化參數(shù)，-XX:Metaspacesize為21810376B（大約20.8M）。

-XX:MaxMetaspaceSize=N 這個(gè)參數(shù)用于限制Metaspace增長的上限，防止因?yàn)槟承┣闆r導(dǎo)致Metaspace無限的使用本地內(nèi)存，影響到其他程序。在本機(jī)上該參數(shù)的默認(rèn)值為4294967295B（大約4096MB）。

-XX:MinMetaspaceFreeRatio=N 當(dāng)進(jìn)行過Metaspace GC之后，會計(jì)算當(dāng)前Metaspace的空閑空間比，如果空閑比小于這個(gè)參數(shù)，那么虛擬機(jī)將增長Metaspace的大小。在本機(jī)該參數(shù)的默認(rèn)值為40，也就是40%。設(shè)置該參數(shù)可以控制Metaspace的增長的速度，太小的值會導(dǎo)致Metaspace增長的緩慢，Metaspace的使用逐漸趨于飽和，可能會影響之后類的加載。而太大的值會導(dǎo)致Metaspace增長的過快，浪費(fèi)內(nèi)存。

-XX:MaxMetasaceFreeRatio=N 當(dāng)進(jìn)行過Metaspace GC之后， 會計(jì)算當(dāng)前Metaspace的空閑空間比，如果空閑比大于這個(gè)參數(shù)，那么虛擬機(jī)會釋放Metaspace的部分空間。在本機(jī)該參數(shù)的默認(rèn)值為70，也就是70%。

-XX:MaxMetaspaceExpansion=N Metaspace增長時(shí)的最大幅度。在本機(jī)上該參數(shù)的默認(rèn)值為5452592B（大約為5MB）。

-XX:MinMetaspaceExpansion=N Metaspace增長時(shí)的最小幅度。在本機(jī)上該參數(shù)的默認(rèn)值為340784B（大約330KB為）。

以前只認(rèn)為，Metaspace區(qū)是保存在本地內(nèi)存中，是沒有上限的，經(jīng)查閱資料才發(fā)現(xiàn)，原來JDK8中，XX:MaxMetaspaceSize確實(shí)是沒有上限的，最大容量與機(jī)器的內(nèi)存有關(guān)；但是XX:MetaspaceSize是有一個(gè)默認(rèn)值的：21M

-XX:CompressedClassSpaceSize 設(shè)置方法區(qū)類信息加載空間的大小，因?yàn)?CompressedClassSpaceSize的大小是由：MaxMetaspaceSize，InitialBootClassLoaderMetaspaceSize，CompressedClassSpaceSize這三個(gè)參數(shù)共同影響的結(jié)果。具體就是：min_metaspace_sz 加CompressedClassSpaceSize大于 MaxMetaspaceSize的時(shí)候，CompressedClassSpaceSize就強(qiáng)制被設(shè)置為(MaxMetaspaceSize - min_metaspace_sz)。64位下默認(rèn)4M，32位下默認(rèn)2200K

-XX:InitialBootClassLoaderMetaspaceSize 設(shè)置類信息區(qū)，引導(dǎo)類的元空間大小

1.3.1.3 查看類加載與卸載時(shí)候的信息

我增加了如下兩個(gè)JVM啟動參數(shù)來觀察類的加載、卸載信息：

-XX:TraceClassLoading -XX:TraceClassUnloading

nohup java -Xms1g -Xmx1g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./dumplog/dumplog.log -Xloggc:./dumplog/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=1500m -XX:MaxMetaspaceExpansion=50M -XX:MinMetaspaceExpansion=10M -XX:CompressedClassSpaceSize=1200m -XX:+TraceClassUnloading -XX:+TraceClassLoading -jar xxxx.jar > logs/xxx.log 2>&1 &

1.3.2 棧配置

-Xss參數(shù)指定線程的棧大小

1.3.2 直接內(nèi)存配置

參數(shù) -XX:MaxDirectMemorySize

-XX:MaxMetaspaceSize，元空間最大值 -XX:MaxDirectMemorySize，用于設(shè)置直接內(nèi)存的最大值，限制通過 DirectByteBuffer 申請的內(nèi)存 -XX:ReservedCodeCacheSize，用于設(shè)置 JIT 編譯后的代碼存放區(qū)大小，如果觀察到這個(gè)值有限制，可以適當(dāng)調(diào)大，一般夠用即可

1.4 GC 垃圾回收器常見參數(shù)

1.4.1 與串行回收器相關(guān)的參數(shù)

·-XX：+UseSerialGC：在新生代和老年代使用串行回收器。 ·-XX：SurvivorRatio：設(shè)置eden區(qū)大小和survivior區(qū)大小的比例。 ·-XX：PretenureSizeThreshold：設(shè)置大對象直接進(jìn)入老年代的閾值。當(dāng)對象的大小超過這個(gè)值時(shí)，將直接被分配在老年代。 ·-XX：MaxTenuringThreshold：設(shè)置對象進(jìn)入老年代的年齡的最大值。每一次 Minor GC后，對象年齡就加1。任何大于這個(gè)年齡的對象，一定會進(jìn)入老年代。

1.4.2.與并行GC相關(guān)的參數(shù)

·-XX：+UseParNewGC（考慮到兼容性問題，JDK 9、JDK 10已經(jīng)刪除）：在新生代使用并行回收器。 ·-XX：+UseParallelOldGC：老年代使用并行回收器。 ·-XX：ParallelGCThreads：設(shè)置用于垃圾回收的線程數(shù)。通常情況下可以和CPU數(shù)量相等，但在CPU數(shù)量比較多的情況下，設(shè)置相對較小的數(shù)值也是合理的。 ·-XX：MaxGCPauseMillis：設(shè)置最大垃圾回收停頓時(shí)間。它的值是一個(gè)大于0的整數(shù)?；厥掌髟诠ぷ鲿r(shí)，會調(diào)整 Java 堆大小或者其他一些參數(shù)，盡可能地把停頓時(shí)間控制在MaxGCPauseMillis以內(nèi)。 ·-XX：GCTimeRatio：設(shè)置吞吐量大小。它的值是一個(gè) 0 到 100之間的整數(shù)。假設(shè)GCTimeRatio的值為n ，那么系統(tǒng)將花費(fèi)不超過1/（1+n ）的時(shí)間用于垃圾回收。 ·-XX：+UseAdaptiveSizePolicy：打開自適應(yīng)GC策略。在這種模式下，新生代的大小、eden區(qū)和survivior區(qū)的比例、晉升老年代的對象年齡等參數(shù)會被自動調(diào)整，以達(dá)到在堆大小、吞吐量和停頓時(shí)間之間的平衡。

開啟：-XX:+UseAdaptiveSizePolicy

關(guān)閉：-XX:-UseAdaptiveSizePolicy

JDK 1.8 默認(rèn)使用 UseParallelGC 垃圾回收器，該垃圾回收器默認(rèn)啟動了 AdaptiveSizePolicy，會根據(jù)GC的情況自動計(jì)算計(jì)算 Eden、From 和 To 區(qū)的大小。

注意事項(xiàng)： 1、在 JDK 1.8 中，如果使用 CMS，無論 UseAdaptiveSizePolicy 如何設(shè)置，都會將 UseAdaptiveSizePolicy 設(shè)置為 false；不過不同版本的JDK存在差異； 2、UseAdaptiveSizePolicy不要和SurvivorRatio參數(shù)顯示設(shè)置搭配使用，一起使用會導(dǎo)致參數(shù)失效； 3、由于AdaptiveSizePolicy會動態(tài)調(diào)整 Eden、Survivor 的大小，有些情況存在Survivor 被自動調(diào)為很小，比如十幾MB甚至幾MB的可能，這個(gè)時(shí)候YGC回收掉 Eden區(qū)后，還存活的對象進(jìn)入Survivor 裝不下，就會直接晉升到老年代，導(dǎo)致老年代占用空間逐漸增加，從而觸發(fā)FULL GC，如果一次FULL GC的耗時(shí)很長（比如到達(dá)幾百毫秒），那么在要求高響應(yīng)的系統(tǒng)就是不可取的。

1.4.3.與CMS回收器相關(guān)的參數(shù)（JDK9、JDK10已經(jīng)開始廢棄CMS回收器，建議使用G1回收器）

·-XX：+UseConcMarkSweepGC：新生代使用并行回收器，老年代使用CMS+串行回收器。 ·-XX：ParallelCMSThreads：設(shè)定CMS的線程數(shù)量。 ·-XX：CMSInitiatingOccupancyFraction：設(shè)置 CMS 回收器在老年代空間被使用多少后觸發(fā)，默認(rèn)為68%。 ·-XX：+UseCMSCompactAtFullCollection：設(shè)置 CMS 回收器在完成垃圾回收后是否要進(jìn)行一次內(nèi)存碎片的整理。 ·-XX：CMSFullGCsBeforeCompaction：設(shè)定進(jìn)行多少次CMS垃圾回收后，進(jìn)行一次內(nèi)存壓縮。 ·-XX：+CMSClassUnloadingEnabled：允許對類元數(shù)據(jù)區(qū)進(jìn)行回收。 ·-XX：CMSInitiatingPermOccupancyFraction：當(dāng)永久區(qū)占用率達(dá)到這一百分比時(shí)，啟動CMS回收（前提是激活了-XX：+CMSClassUnloadingEnabled）。 ·-XX：UseCMSInitiatingOccupancyOnly：表示只在到達(dá)閾值的時(shí)候才進(jìn)行CMS回收。 ·-XX：+CMSIncrementalMode：使用增量模式，比較適合單CPU。增量模式在JDK8中標(biāo)記為廢棄，并且將在JDK9中徹底移除。

1.4.4.與G1回收器相關(guān)的參數(shù)

·-XX：+UseG1GC：使用G1回收器。 ·-XX：MaxGCPauseMillis：設(shè)置最大垃圾回收停頓時(shí)間。 ·-XX：GCPauseIntervalMillis：設(shè)置停頓間隔時(shí)間。

1.4.5.TLAB相關(guān)

·-XX：+UseTLAB：開啟TLAB分配。 ·-XX：+PrintTLAB（考慮到兼容性問題，JDK 9、JDK 10不再支持此參數(shù)）：打印TLAB相關(guān)分配信息。 ·-XX：TLABSize：設(shè)置TLAB區(qū)域大小。 ·-XX：+ResizeTLAB：自動調(diào)整TLAB區(qū)域大小。

1.4.6.其他參數(shù)

·-XX：+DisableExplicitGC：禁用顯式GC。 ·-XX：+ExplicitGCInvokesConcurrent：使用并發(fā)方式處理顯式GC。

1.5 GC 日志打印

1.5.1 JDK8 GC 日志打印參數(shù)

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+UseSerialGC -Xmx1m -Xloggc:./gc-serial.log

參數(shù) 功能

-XX:+PrintGC 使用這個(gè)參數(shù)啟動Java虛擬機(jī)后，只要遇到GC，就會打印日志

-XX:+PrintGCDetails 輸出GC的詳細(xì)日志，參數(shù)-XX:+PrintGCDetails還會使虛擬機(jī)在退出前打印堆的詳細(xì)信息，詳細(xì)信息描述了當(dāng)前堆的各個(gè)區(qū)間的使用情況

-XX:+PrintGCTimeStamps 輸出GC的時(shí)間戳（以基準(zhǔn)時(shí)間的形式）

-XX:+PrintGCDateStamps 輸出GC的時(shí)間戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）

-XX:+PrintHeapAtGC 在進(jìn)行GC的前后打印出堆的信息。還可以使用參數(shù)-XX:+PrintHeapAtGC（考慮到兼容性，從JDK9開始已經(jīng)刪除此參數(shù)，查看堆信息可以使用VisualVM，第6章將會講述）

-Xloggc:gc.log 日志文件的輸出路徑

該日志顯示，一共進(jìn)行了4次GC，每次GC占用一行，在GC前，堆空間使用量約為4MB，在GC后，堆空間使用量為377KB，當(dāng)前可用的堆空間總和約為16MB（15936KB）。最后，顯示的是本次GC所 花的時(shí)間。

1.5.2 JDK9、JDK10 GC日志參數(shù)

.-XX:+PrintGC（在JDK9、JDK10中建議使用-Xlog:gc），使用這個(gè)參數(shù)啟動Java虛擬機(jī)后，只要遇到GC，就會打印日志,JDK9、JDK10默認(rèn)使用G1作為垃圾回收器，使用參數(shù)-Xlog:gc來打印GC日志

-Xlog:gc* 打印GC 日志詳情，JDK9、JDK10建議使用-Xlog:gc*

-XX:+PrintHeapAtGC 在進(jìn)行GC的前后打印出堆的信息。還可以使用參數(shù)-XX:+PrintHeapAtGC（考慮到兼容性，從JDK9開始已經(jīng)刪除此參數(shù)，查看堆信息可以使用VisualVM，第6章將會講述）

從這個(gè)輸出中可以看到，系統(tǒng)經(jīng)歷了3次GC，第1次僅為新生代GC，回收的效果是新生代從回收前的8MB左右降低到1MB。整個(gè)堆從22MB左右降低到17MB。 第2次（加粗部分）為Full GC，它同時(shí)回收了新生代、老年代和永久區(qū)。日志顯示，新生代在這次GC中沒有釋放空間（嚴(yán)格來說，這是GC日志的一個(gè)小bug，事實(shí)上，在這次FullGC完成后，新生代被清空，由于GC日志輸出時(shí)機(jī)的關(guān)系，各個(gè)版本JDK的日志多少有些不太精確的地方，讀者需要留意），老年代從16MB降低到13MB。整個(gè)堆大小從26MB左右降低為13MB左右（這個(gè)大小完全與老年代 實(shí)際大小相等，因此也可以推斷，新生代實(shí)際上已被清空）。永久區(qū)的大小沒有變化。日志的最后顯示了GC所花的時(shí)間，其中user表示用戶態(tài)CPU耗時(shí)，sys表示系統(tǒng)CPU耗時(shí)，real表示GC實(shí)際經(jīng)歷的時(shí)間。

透過日志看垃圾收集器

Serial收集器：新生代顯示 “[DefNew”，即 Default New Generation ParNew收集器：新生代顯示“[ParNew”，即 Parallel New Generation Parallel Scavenge收集器：新生代顯示"[PSYoungGen"，JDK1.7使用的即PSYoungGen Parallel Old收集器：老年代顯示"[ParoldGen" G1收集器：顯示”garbage-first heap“

1.6 GC 日志分析

參考 https://www.cnblogs.com/dtyy/p/15873735.html 參考 https://blog.csdn.net/xyz9353/article/details/119190661

柚子快報(bào)激活碼778899分享：JVM 常見配置參數(shù)

http://yzkb.51969.com/

文章來源