[转帖]谈 JVM 参数 GC 线程数 ParallelGCThreads 合理性设置

https://my.oschina.net/u/4090830/blog/7926038

1. ParallelGCThreads 参数含义

在讲这个参数之前，先谈谈 JVM 垃圾回收 (GC) 算法的两个优化标的：吞吐量和停顿时长。JVM 会使用特定的 GC 收集线程，当 GC 开始的时候，GC 线程会和业务线程抢占 CPU 时间，吞吐量定义为 CPU 用于业务线程的时间与 CPU 总消耗时间的比值。为了承接更大的流量，吞吐量越大越好。

为了安全的垃圾回收，在 GC 或者 GC 某个阶段，所有业务线程都会被暂停，也就是 STW（Stop The World)，STW 持续时间就是停顿时长，停顿时长影响响应速度，因此越小越好。

这两个优化目标是有冲突的，在一定范围内，参与 GC 的线程数越多，停顿时长越小，但吞吐量也越小。生产实践中，需要根据业务特点设置一个合理的 GC 线程数，取得吞吐量和停顿时长的平衡。

目前广泛使用的 GC 算法，包括 PS MarkSweep/PS Scavenge, ConcurrentMarkSweep/ParNew, G1 等，都可以通过 ParallelGCThreads 参数来指定 JVM 在并行 GC 时参与垃圾收集的线程数。该值设置过小，GC 暂停时间变长影响 RT，设置过大则影响吞吐量，从而导致 CPU 过高。

2. ParallelGCThreads 参数设置

GC 并发线程数可以通过 JVM 启动参数: -XX:ParallelGCThreads=<N> 来指定。在未明确指定的情况下，JVM 会根据逻辑核数 ncpus，采用以下公式来计算默认值：

◦当 ncpus 小于 8 时，ParallelGCThreads = ncpus

◦否则 ParallelGCThreads = 8 + (ncpus - 8) ( 5/8 )

一般来说，在无特殊要求下，ParallelGCThreads 参数使用默认值就可以了。但是在 JRE 版本 1.8.0_131 之前，JVM 无法感知 Docker 的 CPU 限制，会使用宿主机的逻辑核数计算默认值。 比如部署在 128 核物理机上的容器，JVM 中默认 ParallelGCThreads 为 83，远超过了容器的核数。过多的 GC 线程数抢占了业务线程的 CPU 时间，加上线程切换的开销，较大的降低了吞吐量。因此 JRE 1.8.0_131 之前的版本，未明确指定 ParallelGCThreads 会有较大的风险。

3. ParallelGCThreads 参数实验

创建 8C12G 容器，宿主机是 128C。模拟线上真实流量，采用相同 QPS，观察及对比 JVM YoungGC，JVM CPU，容器 CPU 等监控数据。场景如下：

◦场景 1: JVM ParallelGCThreads 默认值，QPS = 420，持续 5 分钟，CPU 恒定在 70%

◦场景 2: JVM ParallelGCThreads=8，QPS = 420，持续 5 分钟，CPU 恒定在 65%

◦场景 3: JVM ParallelGCThreads 默认值，QPS 瞬时发压到 420，前 1min CPU 持续 100%

◦场景 4: JVM ParallelGCThreads=8，QPS 瞬时发压到 420，前 2s CPU 持续 100%，后面回落

从监控数据来看，各场景下 CPU 差距较明显，特别是场景 3 和场景 4 的对比。场景 3 由于 GC 线程过多，CPU 持续 100% 时长达 1 分钟。可以得出以下两个结论：

1. 修改 ParallelGCThreads = 8 后，同等 QPS 情况下，CPU 会降低 5% 左右

2. 修改 ParallelGCThreads = 8 后，瞬间发压且 CPU 打满情况下，CPU 恢复较快

图 1: 容器 CPU 对比图：场景 3 (上) 和场景 4 (下)

  图 2: JVM Young GC 对比图：场景 3 (上) 和场景 4 (下)

4. ParallelGCThreads 修改建议

ParallelGCThreads 配置存在风险的应用，修改方式为以下两种方案（任选一种）：

◦升级 JRE 版本到 1.8.0_131 以上，推荐 1.8.0_192

◦在 JVM 启动参数明确指定 -XX:ParallelGCThreads=<N>，N 为下表的推荐值：

容器核数	2	4	8	16	32	64
推荐值	2	4	8	13	23	43
建议上下界	1~2	2~4	4~8	8~16	16~32	32~64