GC調優(yōu)實戰(zhàn)之過早提升Premature?Promotion

更新時間：2022年01月26日 08:34:05 作者：金色夢想

這篇文章主要為大家介紹了GC調優(yōu)實戰(zhàn)之過早提升Premature?Promotion

過早提升(Premature Promotion)

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

JVM會將長時間存活的對象從年輕代提升到老年代。根據分代假設, 可能存在一種情況, 老年代中不僅有存活時間長的對象,也可能有存活時間短的對象。這就是過早提升：對象存活時間還不夠長的時候就被提升到了老年代。

major GC 不是為頻繁回收而設計的, 但 major GC 現(xiàn)在也要清理這些生命短暫的對象, 就會導致GC暫停時間過長。這會嚴重影響系統(tǒng)的吞吐量。

如何測量提升速率

可以指定JVM參數 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps , 通過GC日志來測量提升速率. JVM記錄的GC暫停信息如下所示:

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之前和之后的年輕代使用量以及堆內存使用量。這樣就可以通過差值算出老年代的使用量。GC日志中的信息可以表述為:

Event	Time	Young decreased	Total decreased	Promoted	Promotion rate
(事件)	(耗時)	(年輕代減少)	(整個堆內存減少)	(提升量)	(提升速率)
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

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

請注意, 只能根據 minor GC 計算提升速率。 Full GC 的日志不能用于計算提升速率, 因為 major GC 會清理掉老年代中的一部分對象。

提升速率的意義

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

此前說過, full GC 通常需要更多的時間, 因為需要處理更多的對象, 還要執(zhí)行碎片整理等額外的復雜過程。

示例

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

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 程序受到過早提升的影響。下文將進行驗證并給出解決辦法。

過早提升的影響

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

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

要演示這種情況稍微有點麻煩, 所以我們使用特殊手段, 讓對象提升到老年代的年齡比默認情況小很多。指定GC參數 -Xmx24m -XX:NewSize=16m -XX:MaxTenuringThreshold=1, 運行程序之后,可以看到下面的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]

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

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

解決方案

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

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

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]

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

如果都不可行, 就只能優(yōu)化數據結構, 減少內存消耗。但總體目標依然是一致的: 讓臨時數據能夠在年輕代存放得下。

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

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

您可能感興趣的文章: