转载

记一次简单的 JVM 调优

背景

最近对负责的项目进行了一次性能优化，其中包括对 JVM 参数的调整，算是进行了一次简单的 JVM 调优，JVM 参数调整之后，服务的整体性能有 5% 左右的提升，还算不错。

先介绍一下项目的基本情况：

项目是一个高 QPS 压力的 web 服务，单机 QPS 一直维持在 1.5K 以上，由于旧机器的”拖累”，配置的堆大小是 8G，其中 young 区是 4G，垃圾回收器用的是 parNew + CMS。

转载随意，文章会持续修订，请注明来源地址： https://zhenbianshu.github.io 。

旧状

首先是查看当前 GC 的情况，主要是使用 jstat 查看 GC 的概况，再查看 gc log，分析单次 gc 的详细状况。

使用 jstat -gcutil pid 1000 每隔一秒打印一次 gc 统计信息。

记一次简单的 JVM 调优

可以看到，单次 gc 平均耗时是 60ms 左右，还算可以接受，但 YGC 非常频繁，基本上每秒一次，有的时候还会一秒两次，在一秒两次的时候，服务对业务响应时长的压力就会变得很大。

接着查看 gc log，打印 gc log 需要在 JVM 启动参数里添加以下参数：

-XX:+PrintGCDateStamps
-XX:+PrintTenuringDistribution
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintGCDetails
-Xloggc:../gclogs/gc.log.date

看到的 gc log 形如：

记一次简单的 JVM 调优

单次 GC 方面并不能直接看出问题，但可以看到 gc 前有很多次 18ms 左右的停顿。

分析和调整

YGC 频繁

直接查看 gc log 并不直观，我们可以借用一些可视化工具来帮助我们分析， [gceasy](https://gceasy.io/) 是个挺不错的网站，我们把 gc log 上传上去后， gceasy 可以帮助我们生成各个维度的图表帮助分析。

查看 gceasy 生成的报告，发现我们服务的 gc 吞吐量是 95%，它指的是 JVM 运行业务代码的时长占 JVM 总运行时长的比例，这个比例确实有些低了，运行 100 分钟就有 5 分钟在执行 gc。幸好这些 GC 中绝大多数都是 YGC，单次时长可控且分布平均，这使得我们服务还能平稳运行。

解决这个问题要么是减少对象的创建，要么就增大 young 区。前者不是一时半会儿都解决的，需要查找代码里可能有问题的点，分步优化。

而后者虽然改一下配置就行，但以我们对 GC 最直观的印象来说，增大 young 区，YGC 的时长也会迅速增大。

其实这点不必太过担心，我们知道 YGC 的耗时是由 GC 标记 + GC 复制 组成的，相对于 GC 复制，GC 标记是非常快的。而 young 区内大多数对象的生命周期都非常短，如果将 young 区增大一倍，GC 标记的时长会提升一倍，但到 GC 发生时被标记的对象大部分已经死亡， GC 复制的时长肯定不会提升一倍，所以我们可以放心增大 young 区大小。

由于低内存旧机器都被换掉了，我把堆大小调整到了 12G，young 区保留为 8G。

分代调整

除了 GC 太频繁之外，GC 后各分代的平均大小也需要调整。

记一次简单的 JVM 调优

我们知道 GC 的提升机制，每次 GC 后，JVM 存活代数大于 MaxTenuringThreshold 的对象提升到老年代。当然，JVM 还有动态年龄计算的规则：按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了 survivor 区的一半时，取这个年龄和 MaxTenuringThreshold 中更小的一个值，作为新的晋升年龄阈值，但看各代总的内存大小，是达不到 survivor 区的一半的。

记一次简单的 JVM 调优