什么是升职率？

我确实相信您熟悉彼得原则。一般而言，该原则是一种观察，即晋升可能并且将导致晋升人员不再符合该职位的条件。

对于JVM，存在类似的问题。太快地提升对象可能会对性能产生重大影响。在这篇文章中，我们将探讨提升率的概念，演示如何衡量它并解释该概念的实际价值。

这是上周我们帖子的后续工作，解释了分配率的概念。

提升率是按照每个时间单位从年轻一代传播到老一代的数据量来衡量的 。它通常以MB /秒为单位进行测量，类似于分配速率。与我们有关分配率的帖子类似，让我们再次更深入地了解升职率是如何计算的，以及为什么您应该完全关心升职率。

衡量促销率

让我们从衡量促销率开始。为此，我们通过为JVM指定-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]

从上面我们可以提取收集事件之前和之后的Young Generation大小和总堆大小。知道了年轻一代的消耗和总堆，很容易将老一代的消耗计算为两者之间的增量。将GC日志中的信息表示为：

事件	时间	年轻减少	总数减少	晋升	提升率
第一GC	291ms	28192千	892万	19,272千	66.2 MB /秒
第二GC	446毫秒	33,248千	11,400千	21,848千	140.95 MB /秒
第三GC	829毫秒	66,560千	30,888千	35,672千	93.14 MB /秒
总	829毫秒			76,792千	92.63 MB /秒

可以让我们提取出所测期间的促销率。我们可以看到，平均提升速度为92 MB /秒，有一段时间达到了140.95 MB /秒的峰值。

现在，掌握了提升率的定义并知道如何衡量它，让我们看一下这些信息的实用价值。

再次，类似于分配率，提升率的主要影响是GC暂停频率的变化。但是，与分配率会影响次要GC事件的发生频率相反，提升率会影响主要GC事件的发生频率。让我解释一下-您向老一代人宣传的东西越多，填满它的速度就越快。更快地填充Old gen意味着清理GC的GC事件的频率将增加。

Java垃圾收集的工作原理

从实践的角度来看，面对高晋升率可能会浮现出称为过早晋升的问题的症状。为了解释这个问题，让我们回顾一下为什么JVM堆首先被划分为不同的内存池。其原因基于以下观察：

大多数对象很快就变得不可用
那些通常不能存活（很长时间）的人

这些观点在弱代假说中并存 。基于此假设，VM内的内存分为年轻一代和老一代（或终身一代）。具有此类单独且可单独清洁的区域使GC可以应用不同的算法来清洁这些区域，从而提高GC的性能。

因此，当预期寿命短的物体没有在年轻一代中收集并晋升为老一代时，就会发生过早的提升 。清理此类对象成为Major GC的工作，该对象不适用于频繁运行，并且会导致GC暂停时间更长，从而严重影响应用程序的吞吐量。

表示应用程序遭受过早升级的症状是升级率接近分配率 。就我们而言，我们肯定会遇到这样的问题，因为我们的分配速率为161 MB /秒，提升速率为92 MB /秒。解决这个问题的方法可能很简单，就是通过更改-XX：NewSize ， -XX：MaxNewSize和-XX：SurvivorRatio参数来增加年轻一代的大小。

在许多情况下，这仍将导致次要GC运行过于频繁。在这种情况下，您将需要更改应用程序并降低分配率。如何实现此目标是非常特定于应用程序的，但是为经常创建的对象引入缓存可能是解决此问题的一种方法。