過(guò)早提升(Premature Promotion)

提升速率(promotion rate), 用于衡量單位時(shí)間內(nèi)從年輕代提升到老年代的數(shù)據(jù)量。一般使用 MB/sec 作為單位, 和分配速率類似。

JVM會(huì)將長(zhǎng)時(shí)間存活的對(duì)象從年輕代提升到老年代。根據(jù)分代假設(shè), 可能存在一種情況, 老年代中不僅有存活時(shí)間長(zhǎng)的對(duì)象,也可能有存活時(shí)間短的對(duì)象。這就是過(guò)早提升：對(duì)象存活時(shí)間還不夠長(zhǎng)的時(shí)候就被提升到了老年代。

major GC 不是為頻繁回收而設(shè)計(jì)的, 但 major GC 現(xiàn)在也要清理這些生命短暫的對(duì)象, 就會(huì)導(dǎo)致GC暫停時(shí)間過(guò)長(zhǎng)。這會(huì)嚴(yán)重影響系統(tǒng)的吞吐量。

如何測(cè)量提升速率

可以指定JVM參數(shù) -XX:+PrintGCDetails -XX:+PrintGCTimeStamps , 通過(guò)GC日志來(lái)測(cè)量提升速率. JVM記錄的GC暫停信息如下所示:

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

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

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

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

提升速率的意義

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

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

示例

讓我們看一個(gè)過(guò)早提升的示例。 這個(gè)程序創(chuàng)建/獲取大量的對(duì)象/數(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 程序 受到過(guò)早提升的影響。下文將進(jìn)行驗(yàn)證并給出解決辦法。

過(guò)早提升的影響

一般來(lái)說(shuō),過(guò)早提升的癥狀表現(xiàn)為以下形式:

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

要演示這種情況稍微有點(diǎn)麻煩, 所以我們使用特殊手段, 讓對(duì)象提升到老年代的年齡比默認(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]

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

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

解決方案

簡(jiǎn)單來(lái)說(shuō), 要解決這類問(wèn)題, 需要讓年輕代存放得下暫存的數(shù)據(jù)。有兩種簡(jiǎn)單的方法:

一是增加年輕代的大小, 設(shè)置JVM啟動(dòng)參數(shù), 類似這樣: -Xmx64m -XX:NewSize=32m, 程序在執(zhí)行時(shí), Full GC 的次數(shù)自然會(huì)減少很多, 只會(huì)對(duì) 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)之過(guò)早提升Premature Promotion的詳細(xì)內(nèi)容，更多關(guān)于GC調(diào)優(yōu)過(guò)早提升的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

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

最新評(píng)論