JAVA中GC日志的相關知識有哪些

這篇文章主要為大家展示了“JAVA中GC日志的相關知識有哪些”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“JAVA中GC日志的相關知識有哪些”這篇文章吧。

創新互聯是一家集網站建設,商州企業網站建設,商州品牌網站建設,網站定制,商州網站建設報價,網絡營銷,網絡優化,商州網站推廣為一體的創新建站企業，幫助傳統企業提升企業形象加強企業競爭力。可充分滿足這一群體相比中小企業更為豐富、高端、多元的互聯網需求。同時我們時刻保持專業、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們為更多的企業打造出實用型網站。

GC環境模擬

首先我們給出如下代碼用來觸發GC

public static void main(String[] args) {
// 每100毫秒創建100線程，每個線程創建一個1M的對象，即每100ms申請100M堆空間
Executors.newScheduledThreadPool(1).scheduleAtFixedRate(() -> {
for (int i = 0; i < 100; i++) {
new Thread(() -> {
try {
// 申請1M
byte[] temp = new byte[1024 * 1024];
Thread.sleep(new Random().nextInt(1000)); // 隨機睡眠1秒以內
} catch (InterruptedException e) {
e.printStackTrace();
}
}).start();
}
}, 1000, 100, TimeUnit.MILLISECONDS);
}

我們要模擬的場景是年輕代不斷地Young GC，并有一部分對象晉升到老年代，當老年代空間不足時觸發Full GC。

程序邏輯：每100毫秒鐘創建100個線程，每個線程創建一個1M的對象，即每100ms申請100M堆空間。之所以每個線程隨機睡眠1s，是為了避免對象朝生夕滅，保證可以有一部分對象能晉升到老年代，更好的觸發Young GC 和 Full GC，注意這個睡眠時間如果大了，會導致OOM，如果小了，很難觸發FULL GC。

虛擬機參數解釋

啟動Java進程：java -Xms200m -Xmx200m -Xmn100m -verbose:gc -XX:+PrintGCDetails -Xloggc:./gc.log -XX:+PrintGCDateStamps -jar demo-0.0.1-SNAPSHOT.jar

-Xms200m -Xmx200m 最小/最大堆內存 200M

-Xmn100m 年輕代內存 100M

-verbose:gc 開啟GC日志

-XX:+PrintGCDetails -Xloggc:./gc.log -XX:+PrintGCDateStamps 將GC日志詳情輸入到gc.log中

jmap分析

jcmd 獲取我們Java進程的Id：6264

jmap -heap 6264查看堆信息

第一次查看，我們發現 Eden區是98M，S0、S1是1M

JAVA中GC日志的相關知識有哪些

第二次查看， Eden區是99M，S0、S1是0.5M

JAVA中GC日志的相關知識有哪些

Eden區與Survivor區的比例在動態的變化，并不是默認的8:1:1。

原來我們使用默認的垃圾收集器Parallel Scavenge+Parallel Old組合，而該收集器下-XX:+UseAdaptiveSizePolicy是默認開啟的，即Eden區與Survivor區比例根據GC情況會自適應變化。

我們加上參數，關閉年輕代自適應，年輕代比例設置為8:1:1

-XX:-UseAdaptiveSizePolicy -XX:SurvivorRatio=8

另外為了盡早的觸發FULL GC，我們新增虛擬機參數

-XX:MaxTenuringThreshold=10

晉升年齡由默認的15修改為10，使得年輕代的對象更容易晉升到老年代

重啟虛擬機查看jmap

JAVA中GC日志的相關知識有哪些

年輕代

Eden區80M 已使用51M，當前使用率63.8%
S0區10M 已使用0.43M，使用率4.37%
S1區10M 使用率為空

老年代

100M 已使用18.39M，使用率18.9%

GC日志內容分析

查看我們輸出的GC日志gc.log，選取其中兩段

2019-06-09T02:55:30.993+0800: 330.811: [GC (Allocation Failure) [PSYoungGen: 82004K->384K(92160K)] 184303K->102715K(194560K), 0.0035647 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-06-09T02:55:30.997+0800: 330.815: [Full GC (Ergonomics) [PSYoungGen: 384K->0K(92160K)] [ParOldGen: 102331K->5368K(102400K)] 102715K->5368K(194560K), [Metaspace: 16941K->16914K(1064960K)], 0.0213953 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]

Young GC

2019-06-09T02:55:30.993+0800: 330.811: [GC (Allocation Failure) [PSYoungGen: 82004K->384K(92160K)] 184303K->102715K(194560K), 0.0035647 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-06-09T02:55:30.997+0800: 330.815: [Full GC (Ergonomics) [PSYoungGen: 384K->0K(92160K)] [ParOldGen: 102331K->5368K(102400K)] 102715K->5368K(194560K), [Metaspace: 16941K->16914K(1064960K)], 0.0213953 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]

解釋:

年輕代GC：[GC前年輕代80.08M->GC后0.37M(年輕代總大小90M)]GC前堆179.98M->GC后堆100.3M(堆總大小190M)，用時]
其中年輕代總大小是90M而不是100M，這里我理解是年輕代當前最大申請到90M
100M*80%=80M 是Eden區大小
80M*80% = 64M Eden區默認占用超過8成即64M就會觸發YoungGC

Full GC

[Full GC (Ergonomics) [PSYoungGen: 384K->0K(92160K)] [ParOldGen: 102331K->5368K(102400K)] 102715K->5368K(194560K), [Metaspace: 16941K->16914K(1064960K)], 0.0213953 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]

解釋：

[GC前年輕代0.375M->GC后年輕代0M(年輕代總大小90M)][GC前老年代99.93M->GC后老年代5.24M(老年代總大小100M)]GC前堆100.3M->GC后堆5.24M（堆總大小190M）,[元數據區:GC前16.5,GC后16.5(元數據區總大小1040M)]，用時]
可以推測出此次FullGC原因是年輕代晉升老年代空間不足導致

利用可視化工具分析

這里我們利用 gceasy.io/ 分析一下

(1)統計年輕代、老年代、元數據區最大可用空間以及峰值，這里元數據區大小在我們的虛擬機參數沒有配置，所以取的是默認值

JAVA中GC日志的相關知識有哪些