作者：京东零售 刘乐

导读：本篇文章聚焦jvm参数gc线程数的合理配置，从parallelgcthreads参数含义、参数设置，到参数实验以及修改意见进行解析。

谈jvm参数gc线程数parallelgcthreads合理性设置-凯发app官方网站

在讲这个参数之前，先谈谈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过高。

gc并发线程数可以通过jvm启动参数: -xx:parallelgcthreads=来指定。在未明确指定的情况下，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会有较大的风险。

创建 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(下)

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

?升级jre版本到1.8.0_131以上，推荐1.8.0_192

?在jvm启动参数明确指定 -xx:parallelgcthreads=，n为下表的推荐值：