本文來自于HeapDump性能社區(qū)涵妥！ 谨敛！有性能問題柿估，上HeapDump性能社區(qū)跳夭！
正文：
過早提升(Premature Promotion)
提升速率(promotion rate), 用于衡量單位時間內(nèi)從年輕代提升到老年代的數(shù)據(jù)量宜猜。一般使用 MB/sec 作為單位, 和分配速率類似泼返。
JVM會將長時間存活的對象從年輕代提升到老年代。根據(jù)分代假設(shè), 可能存在一種情況, 老年代中不僅有存活時間長的對象,也可能有存活時間短的對象姨拥。這就是過早提升：對象存活時間還不夠長的時候就被提升到了老年代绅喉。
major GC 不是為頻繁回收而設(shè)計的, 但 major GC 現(xiàn)在也要清理這些生命短暫的對象, 就會導(dǎo)致GC暫停時間過長。這會嚴(yán)重影響系統(tǒng)的吞吐量叫乌。
如何測量提升速率
可以指定JVM參數(shù) -XX:+PrintGCDetails -XX:+PrintGCTimeStamps , 通過GC日志來測量提升速率. 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)存使用量柴罐。這樣就可以通過差值算出老年代的使用量。GC日志中的信息可以表述為:
| Event | Time | Young decreased | Total decreased | Promoted | Promotion rate |
|---|---|---|---|---|---|
| (事件) | (耗時) | (年輕代減少) | (整個堆內(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ù)這些信息, 就可以計算出觀測周期內(nèi)的提升速率憨奸。平均提升速率為 92 MB/秒, 峰值為 140.95 MB/秒革屠。
請注意, 只能根據(jù) minor GC 計算提升速率。 Full GC 的日志不能用于計算提升速率, 因為 major GC 會清理掉老年代中的一部分對象排宰。
提升速率的意義
和分配速率一樣, 提升速率也會影響GC暫停的頻率似芝。但分配速率主要影響 minor GC, 而提升速率則影響 major GC 的頻率。有大量的對象提升,自然很快將老年代填滿板甘。 老年代填充的越快, 則 major GC 事件的頻率就會越高党瓮。
此前說過, full GC 通常需要更多的時間, 因為需要處理更多的對象, 還要執(zhí)行碎片整理等額外的復(fù)雜過程。
示例
讓我們看一個過早提升的示例盐类。 這個程序創(chuàng)建/獲取大量的對象/數(shù)據(jù),并暫存到集合之中, 達到一定數(shù)量后進行批處理:
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)為以下形式:
- 短時間內(nèi)頻繁地執(zhí)行 full GC。
- 每次 full GC 后老年代的使用率都很低, 在10-20%或以下枪萄。
- 提升速率接近于分配速率隐岛。
要演示這種情況稍微有點麻煩, 所以我們使用特殊手段, 讓對象提升到老年代的年齡比默認情況小很多。指定GC參數(shù) -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逻悠。
解決方案
簡單來說, 要解決這類問題, 需要讓年輕代存放得下暫存的數(shù)據(jù)元践。有兩種簡單的方法:
一是增加年輕代的大小, 設(shè)置JVM啟動參數(shù), 類似這樣: -Xmx64m -XX:NewSize=32m, 程序在執(zhí)行時, Full GC 的次數(shù)自然會減少很多, 只會對 minor GC的持續(xù)時間產(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é)果. 至于選用哪個方案, 要根據(jù)業(yè)務(wù)需求決定。在某些情況下, 業(yè)務(wù)邏輯不允許減少批處理的數(shù)量, 那就只能增加堆內(nèi)存,或者重新指定年輕代的大小童谒。
如果都不可行, 就只能優(yōu)化數(shù)據(jù)結(jié)構(gòu), 減少內(nèi)存消耗单旁。但總體目標(biāo)依然是一致的: 讓臨時數(shù)據(jù)能夠在年輕代存放得下。
在本系列文章中,介紹了JVM中垃圾收集的實現(xiàn)原理饥伊，以及如何高效地利用GC象浑。
第一篇：什么是垃圾回收？
第六篇：GC 算法實現(xiàn)篇——并發(fā)標(biāo)記-清除
第七篇：GC 算法實現(xiàn)篇——垃圾優(yōu)先算法
第十篇：GC調(diào)優(yōu)實戰(zhàn)篇—高分配速率（High Allocation Rate）
