【JVM性能调优】- 年老代-提升速率

一、JVM垃圾收集相关调优策略

在JVM垃圾收集相关的调优实践中，通常都是以最优吞吐量和最短停顿时间来评价JVM的性能：吞吐量越高代表性能越好、暂停时间越短也代表越好。那么如何做到这两点呢？核心思想在于：

尽可能让对象在新生代中分配和回收。
尽量避免过多对象进入年老代，缩短年老代GC时间。
尽量给JVM分配足够多的内存，减少所有区域中的GC次数。

归根结底，本质思想就一点：“尽量让Java中的对象去到它自己该去的位置”，短命的对象就老老实实的进入新生代区域，大对象和长命的对象则进入年老代空间，避免JVM因为对象“乱窜”导致GC频发和GC时间变长，如：

本该在新生代的短命对象由于特殊原因进了年老代，导致年老代GC次数变多/时间变长。
本该直接分配在年老代的长命大对象，因为某些原因全部被分配在新生代，导致新生代可分配空间变少，引发分配担保机制，造成大量未达到标准的新生代对象提前进入年老代。

因此，GC调优的目的就相当于给JVM做“保养”，让其每个区域按照设计的初衷正常工作。

通常情况下，当JVM存在性能问题时，都会牵扯到两个概念，分配速率(Allocation Rate)和提升速率(Promotion Rate)，这也是分析性能问题时常用的两个指标，其中分配速率影响新生代的垃圾回收，提升速率影响年老代的垃圾回收。

1.2、年老代-提升速率(`Promotion Rate`)

前面分析的分配速率仅会对新生代空间造成影响，而影响年老代空间的则是另外一个指标：提升速率，也就是指定时间内，新生代升入年老代空间的对象总量，通常单位也为MB/S。

在前面谈论分配速率时，可以根据GC日志计算新生代的分配占比，但新生代升入年老代空间的提升速率又该如何计算呢？因为MajorGC一般都是伴随着FullGC一起发生的，所以无法根据MajorGC计算，比较FullGC时会回收整堆空间。

1.2.1、提升速率如何计算？

同样计算提升速率时，依旧是通过MinorGC日志来计算：

1.514: [GC (Allocation Failure) [PSYoungGen: 38395K->5120K(71680K)]45665K->35687K(159232K), 0.0570688 secs] [Times: user=0.09 sys=0.00, real=0.06 secs] 
3.018: [GC (Allocation Failure) [PSYoungGen: 70326K->5104K(71680K)]100894K->105240K(172032K), 0.0866792 secs] [Times: user=0.30 sys=0.02, real=0.09 secs]

提升速率计算公式：((新生代回收前使用总量-新生代回收后使用总量)-(整堆回收前使用总量-整堆回收后使用总量))/(本轮GC时间-上轮GC时间)

GC轮数	时间差值	新生代减少	整堆减少	提升量	提升速率
第一轮	763ms	33275KB	9978KB	23297KB	≈30MB/S
第二轮	1504ms	65222KB	3700KB	61522KB	≈40MB/S
每轮均速	NULL	NULL	NULL	NULL	≈35MB/S

结果如上表，此刻是通过MinorGC日志来计算的提升速率，拆解前面的计算公式可以分析出整体的计算逻辑：

先通过新生代回收前后的已使用容量大小，计算出新生代中减少容量。
再通过整堆回收前后的已使用容量大小，计算出整个堆空间的减少容量。
再通过新生代减少-整堆减少，这样可以大致算出新生代中提升到年老代的提升量。
- 该方式只能计算出大概的提升量，因为整堆减少会包含年老代、元空间等区域回收。
在通过本次GC触发时间-上次GC触发时间，得到本轮GC中程序正常执行的时长。
最后通过提示量除执行时长，即可得到JVM的大概提升速率。

不过在计算提升速率的时候，有个点需要额外注意：Java应用启动后的第一条GC日志不能参与计算，因为第一条GC日志是程序启动后，初次触发GC时输出的，此时堆空间刚从“冷状态”启动，因此测算出的速率并非程序正常执行时的提升速率。

1.2.2、提升速率对JVM的影响

和分配速率相同，提升速率也一样会影响GC，但它影响的是年老代空间，速率越快也就代表着提升的对象越多，年老代空间被填满的时间会更短，MajorGC被触发的频率也会越快。不过通常情况下，年老代的GC一般会伴随着FullGC一起发生，因此，提升速率越高会最终导致FullGC频率越快。

1.2.3、进入年老代的三种异常情况

①代码存在内存泄漏

当代码中存在内存泄漏时，会造成堆内存被一点点蚕食，最终导致新生代空间没有空闲内存分配新对象，从而触发JVM的空间分代担保机制，开启对象动态晋升阈值判定，将大量原本未达晋升标准的对象提前迁入年老代空间，以确保新生代拥有足够的空闲内存维护Java应用的正常执行。
常发性内存泄漏、偶发性内存泄漏、一次性内存泄漏、隐式内存泄漏，不同性质的内存泄漏造成的提升速率增长也不同，后两者引发的速率增长并不大，但前两者，尤其是常发性内存泄漏会带来很大的隐患，最终必然会引发OOM。

②频繁的大对象分配

在分代堆中有这么一条法则：“超过指定阈值的大对象会被直接送往年老代空间”，这条结论是依据对象特性而制定的，正常情况下，大对象都不会是“朝生夕死”的对象，一般都能够“活”到成功晋升。因此，为了节省大对象在两个Survivor区中反复挪动带来的开销，JVM会将超过阈值标准的大对象直接分配到年老代。
大对象直接进入年老代是合理的，但频繁的大对象分配是不合理的，会导致年老代被快速填满，因而频繁触发FullGC。
大对象直接进入年老代空间，因此大对象分配是不参与前述的提升速率计算公式的。

③高并发/大流量压力

当系统业务暴涨时，巨大的流量和并发冲击会导致业务线程创建更多的新对象，因而会导致新生代的GC阈值被频繁触发，加快了新生代整体的晋升速度，从而导致提升速率暴涨。
对于这类正常业务增长导致的提升速率变高，这是系统中的常事，这种情况下只需依照具体业务流量的增长，合理的调大堆空间即可。

其实归根结底，上述三点都是在围绕着“对象被过早提升到年老代”这一核心思想展开。对于年老代而言，新生代空间中的所有对象，按部就班的活到15岁再晋升是最佳的状态，因为能够在新生代熬过十多轮GC的对象晋升后，绝大多数情况下会再存活很长一段时间。
但如果是由于上述三种状况导致对象过早提升到年老代空间，则会带来很大的不稳定因素，有可能很多提早晋升的对象刚晋升，没熬过几轮GC就“死”了，从而违背了“年老代存放长命对象”的设计初衷。同时，过早提升还会造成年老代会被快速填满，从而频繁触发FullGC，最终导致Java应用暂停时间过长，影响系统整体的吞吐量。