0.291: [GC (Allocation Failure)
[PSYoungGen: 33280K-&gt;5088K(38400K)]
33280K-&gt;24360K(125952K), 0.0365286 secs]
[Times: user=0.11 sys=0.02, real=0.04 secs]
0.446: [GC (Allocation Failure)
[PSYoungGen: 38368K-&gt;5120K(71680K)]
57640K-&gt;46240K(159232K), 0.0456796 secs]
[Times: user=0.15 sys=0.02, real=0.04 secs]
0.829: [GC (Allocation Failure)
[PSYoungGen: 71680K-&gt;5120K(71680K)]
112800K-&gt;81912K(159232K), 0.0861795 secs]
[Times: user=0.23 sys=0.03, real=0.09 secs]

從上面的日志可以得知： GC之前和之后的年輕代使用量以及堆內(nèi)存使用量。這樣就可以通過差值算出老年代的使用量。GC日志中的信息可以表述為:

Event	Time	Young decreased	Total decreased	Promoted	Promotion rate
(事件)	(耗時(shí))	(年輕代減少)	(整個(gè)堆內(nèi)存減少)	(提升量)	(提升速率)
1st GC	291ms	28,192K	8,920K	19,272K	66.2 MB/sec
2nd GC	446ms	33,248K	11,400K	21,848K	140.95 MB/sec
3rd GC	829ms	66,560K	30,888K	35,672K	93.14 MB/sec
Total	829ms			76,792K	92.63 MB/sec

根據(jù)這些信息, 就可以計(jì)算出觀測周期內(nèi)的提升速率。平均提升速率為 92 MB/秒, 峰值為 140.95 MB/秒。

請注意, 只能根據(jù) minor GC 計(jì)算提升速率。 Full GC 的日志不能用于計(jì)算提升速率, 因?yàn)?major GC 會(huì)清理掉老年代中的一部分對象。

提升速率的意義

和分配速率一樣, 提升速率也會(huì)影響GC暫停的頻率。但分配速率主要影響 minor GC, 而提升速率則影響 major GC 的頻率。有大量的對象提升,自然很快將老年代填滿。老年代填充的越快, 則 major GC 事件的頻率就會(huì)越高。

此前說過, full GC 通常需要更多的時(shí)間, 因?yàn)樾枰幚砀嗟膶ο? 還要執(zhí)行碎片整理等額外的復(fù)雜過程。

示例

讓我們看一個(gè)過早提升的示例。這個(gè)程序創(chuàng)建/獲取大量的對象/數(shù)據(jù),并暫存到集合之中, 達(dá)到一定數(shù)量后進(jìn)行批處理:

public class PrematurePromotion {
private static final Collection<byte[]> accumulatedChunks
= new ArrayList<>();
private static void onNewChunk(byte[] bytes) {
accumulatedChunks.add(bytes);
if(accumulatedChunks.size() > MAX_CHUNKS) {
processBatch(accumulatedChunks);
accumulatedChunks.clear();
}
}
}

此 Demo 程序受到過早提升的影響。下文將進(jìn)行驗(yàn)證并給出解決辦法。

過早提升的影響

一般來說,過早提升的癥狀表現(xiàn)為以下形式:

短時(shí)間內(nèi)頻繁地執(zhí)行 full GC。
每次 full GC 后老年代的使用率都很低, 在10-20%或以下。
提升速率接近于分配速率。

要演示這種情況稍微有點(diǎn)麻煩, 所以我們使用特殊手段, 讓對象提升到老年代的年齡比默認(rèn)情況小很多。指定GC參數(shù) -Xmx24m -XX:NewSize=16m -XX:MaxTenuringThreshold=1, 運(yùn)行程序之后,可以看到下面的GC日志:

2.176: [Full GC (Ergonomics)
[PSYoungGen: 9216K->0K(10752K)]
[ParOldGen: 10020K->9042K(12288K)]
19236K->9042K(23040K), 0.0036840 secs]
2.394: [Full GC (Ergonomics)
[PSYoungGen: 9216K->0K(10752K)]
[ParOldGen: 9042K->8064K(12288K)]
18258K->8064K(23040K), 0.0032855 secs]
2.611: [Full GC (Ergonomics)
[PSYoungGen: 9216K->0K(10752K)]
[ParOldGen: 8064K->7085K(12288K)]
17280K->7085K(23040K), 0.0031675 secs]
2.817: [Full GC (Ergonomics)
[PSYoungGen: 9216K->0K(10752K)]
[ParOldGen: 7085K->6107K(12288K)]
16301K->6107K(23040K), 0.0030652 secs]

乍一看似乎不是過早提升的問題。事實(shí)上,在每次GC之后老年代的使用率似乎在減少。但反過來想, 要是沒有對象提升或者提升率很小, 也就不會(huì)看到這么多的 Full GC 了。

簡單解釋一下這里的GC行為: 有很多對象提升到老年代, 同時(shí)老年代中也有很多對象被回收了, 這就造成了老年代使用量減少的假象. 但事實(shí)是大量的對象不斷地被提升到老年代, 并觸發(fā) full GC。

解決方案

簡單來說, 要解決這類問題, 需要讓年輕代存放得下暫存的數(shù)據(jù)。有兩種簡單的方法:

一是增加年輕代的大小, 設(shè)置JVM啟動(dòng)參數(shù), 類似這樣: -Xmx64m -XX:NewSize=32m, 程序在執(zhí)行時(shí), Full GC 的次數(shù)自然會(huì)減少很多, 只會(huì)對 minor GC的持續(xù)時(shí)間產(chǎn)生影響:

2.251: [GC (Allocation Failure)
[PSYoungGen: 28672K->3872K(28672K)]
37126K->12358K(61440K), 0.0008543 secs]
2.776: [GC (Allocation Failure)
[PSYoungGen: 28448K->4096K(28672K)]
36934K->16974K(61440K), 0.0033022 secs]

二是減少每次批處理的數(shù)量, 也能得到類似的結(jié)果. 至于選用哪個(gè)方案, 要根據(jù)業(yè)務(wù)需求決定。在某些情況下, 業(yè)務(wù)邏輯不允許減少批處理的數(shù)量, 那就只能增加堆內(nèi)存,或者重新指定年輕代的大小。

如果都不可行, 就只能優(yōu)化數(shù)據(jù)結(jié)構(gòu), 減少內(nèi)存消耗。但總體目標(biāo)依然是一致的: 讓臨時(shí)數(shù)據(jù)能夠在年輕代存放得下。

以上就是GC調(diào)優(yōu)實(shí)戰(zhàn)之過早提升Premature Promotion的詳細(xì)內(nèi)容，更多關(guān)于GC調(diào)優(yōu)過早提升的資料請關(guān)注腳本之家其它相關(guān)文章！

原文鏈接：https://plumbr.io/handbook/gc-tuning-in-practice#premature-promotion

您可能感興趣的文章: