高吞吐低延迟Java应用的垃圾回收优化

1. 1. 降低GC频率

在分代GC算法中，降低回收频率可以通过：(1)降低对象分配/提升率；(2)增加代空间的大小。

在Hotspot JVM中，新生代GC停顿时间取决于一次垃圾回收后对象的数量，而不是新生代自身的大小。增加新生代大小对于应用性能的影响需要仔细评估：

1. 如果更多的数据存活而且被复制到survivor区域，或者每次垃圾回收更多的数据提升到老年代，增加新生代大小可能导致更长的新生代GC停顿。
2. 另一方面，如果每次垃圾回收后存活对象数量不会大幅增加，停顿时间可能不会延长。在这种情况下，减少GC频率可能使应用总体延迟降低和(或)吞吐量增加。

对于大部分为短期存活对象的应用，仅仅需要控制前面所说的参数。对于创建长期存活对象的应用，就需要注意，被提升的对象可能很长时间都不能被老年代GC周期回收。如果老年代GC触发阈值(老年代空间占用率百分比)比较低，应用将陷入不断的GC周期。设置高的GC触发阈值可避免这一问题。

由于我们的应用在堆中维持了长期存活对象的较大缓存，将老年代GC触发阈值设置为-XX:CMSInitiatingOccupancyFraction=92 -XX:+UseCMSInitiatingOccupancyOnly。我们也试图增加新生代大小来减少新生代回收频率，但是并没有采用，因为这增加了应用延迟。

1. 1. 缩短GC停顿时间

减少新生代大小可以缩短新生代GC停顿时间，因为这样被复制到survivor区域或者被提升的数据更少。但是，正如前面提到的，我们要观察减少新生代大小和由此导致的GC频率增加对于整体应用吞吐量和延迟的影响。新生代GC停顿时间也依赖于tenuring threshold(提升阈值)和空间大小(见第6步)。

使用CMS尝试最小化堆碎片和与之关联的老年代垃圾回收full GC停顿时间。通过控制对象提升比例和减小-XX:CMSInitiatingOccupancyFraction的值使老年代GC在低阈值时触发。所有选项的细节调整和他们相关的权衡，请查看Web Services的Java 垃圾回收和Java 垃圾回收精粹。

我们观察到Eden区域的大部分新生代被回收，几乎没有对象在survivor区域死亡，所以我们将tenuring threshold从8降低到2(使用选项：-XX:MaxTenuringThreshold=2),为的是缩短新生代垃圾回收消耗在数据复制上的时间。

我们也注意到新生代回收停顿时间随着老年代空间占用率上升而延长。这意味着来自老年代的压力使得对象提升花费更多的时间。为解决这个问题，将总的堆内存大小增加到40GB，减小-XX:CMSInitiatingOccupancyFraction的值到80，更快地开始老年代回收。尽管-XX:CMSInitiatingOccupancyFraction的值减小了，增大堆内存可以避免不断的老年代GC。在本阶段，我们获得了70ms新生代回收停顿和百分之99.9延迟80ms。

1. 1. 优化GC工作线程的任务分配

进一步缩短新生代停顿时间，我们决定研究优化与GC线程绑定任务的选项。

-XX:ParGCCardsPerStrideChunk 选项控制GC工作线程的任务粒度，可以帮助不使用补丁而获得最佳性能，这个补丁用来优化新生代垃圾回收的卡表扫描时间。有趣的是新生代GC时间随着老年代空间的增加而延长。将这个选项值设为32678，新生代回收停顿时间降低到平均50ms。此时百分之99.9应用延迟60ms。

也有其他选项将任务映射到GC线程，如果OS允许的话，-XX:+BindGCTaskThreadsToCPUs选项绑定GC线程到个别的CPU核。-XX:+UseGCTaskAffinity使用affinity参数将任务分配给GC工作线程。然而，我们的应用并没有从这些选项发现任何益处。实际上，一些调查显示这些选项在Linux系统不起作用[1,2]。

 

 

 

 

本教程由尚硅谷教育大数据研究院出品，如需转载请注明来源。