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

1. 1. 了解GC的CPU和内存开销

并发GC通常会增加CPU的使用。我们观察了运行良好的CMS默认设置，并发GC和G1垃圾回收器共同工作引起的CPU使用增加显著降低了应用的吞吐量和延迟。与CMS相比，G1可能占用了应用更多的内存开销。对于低吞吐量的非计算密集型应用，GC的高CPU使用率可能不需要担心。

图2 ParNew/CMS和G1的CPU使用百分数%：相对来说CPU使用率变化明显的节点使用G1
选项-XX:G1RSetUpdatingPauseTimePercent=20

图3 ParNew/CMS和G1每秒服务的请求数：吞吐量较低的节点使用G1
选项-XX:G1RSetUpdatingPauseTimePercent=20

1. 1. 为GC优化系统内存和I/O管理

通常来说，GC停顿发生在(1)低用户时间，高系统时间和高时钟时间和(2)低用户时间，低系统时间和高时钟时间。这意味着基础的进程/OS设置存在问题。情况(1)可能说明Linux从JVM偷页，情况(2)可能说明清除磁盘缓存时Linux启动GC线程，等待I/O时线程陷入内核。在这些情况下如何设置参数可以参考该PPT。

为避免运行时性能损失，启动应用时使用JVM选项-XX:+AlwaysPreTouch访问和清零页面。设置vm.swappiness为零，除非在绝对必要时，OS不会交换页面。

可能你会使用mlock将JVM页pin在内存中，使OS不换出页面。但是，如果系统用尽了所有的内存和交换空间，OS通过kill进程来回收内存。通常情况下，Linux内核会选择高驻留内存占用但还没有长时间运行的进程(OOM情况下killing进程的工作流)。对我们而言，这个进程很有可能就是我们的应用程序。一个服务具备优雅降级(适度退化)的特点会更好，服务突然故障预示着不太好的可操作性——因此，我们没有使用mlock而是vm.swappiness避免可能的交换惩罚。

1. LinkedIn动态信息数据平台的GC优化

对于该平台原型系统，我们使用Hotspot JVM的两个算法优化垃圾回收：

1. 新生代垃圾回收使用ParNew，老年代垃圾回收使用CMS。
2. 新生代和老年代使用G1。G1用来解决堆大小为6GB或者更大时存在的低于0.5秒稳定的、可预测停顿时间的问题。在我们用G1实验过程中，尽管调整了各种参数，但没有得到像ParNew/CMS一样的GC性能或停顿时间的可预测值。我们查询了使用G1发生内存泄漏相关的一个bug[3]，但还不能确定根本原因。

使用ParNew/CMS，应用每三秒40-60ms的新生代停顿和每小时一个CMS周期。JVM选项如下：

// JVM sizing options

-server -Xms40g -Xmx40g -XX:MaxDirectMemorySize=4096m -XX:PermSize=256m -XX:MaxPermSize=256m  

// Young generation options

-XX:NewSize=6g -XX:MaxNewSize=6g -XX:+UseParNewGC -XX:MaxTenuringThreshold=2 -XX:SurvivorRatio=8 -XX:+UnlockDiagnosticVMOptions -XX:ParGCCardsPerStrideChunk=32768

// Old generation  options

-XX:+UseConcMarkSweepGC -XX:CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:+CMSClassUnloadingEnabled  -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly  

// Other options

-XX:+AlwaysPreTouch -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:-OmitStackTraceInFastThrow

使用这些选项，对于几千次读请求的吞吐量，应用百分之99.9的延迟降低到60ms。

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