开发同学反馈应用docker化部署之后，gc时间比KVM部署时涨了好几倍，最近正好手热，上机器撸了一把。
问题定位
通过gc日志收集工具，查看jvm的gc信息，平均单次ygc的时间非常不稳定，但基本上都在100ms以上。
从集群里随机挑了几台机器看了一下gc log，每次gc的堆大小都比较正常，但是时间不太科学。
猜测是gc线程出了问题。jinfo查看了
服务的docker容器分配了8核16g的资源，上面拉出来的gc线程和并发标记线程数是38和10，显然不科学(猜测拉的宿主机的核数)。
默认的gc线程和并发标记线程数计算公式如下：
通过与运维同学沟通，了解到宿主机是56核，根据上面公式进行计算，对上了。
修改配置灰度验证
从集群中随机挑选几台机器进行灰度，修改下jvm启动参数，增加 -XX:ParallelGCThreads=8(8是容器核数），设置了ParallelGCThreads之后CMS的并发标记线程数会同步下降。
运行了一个晚上和一个白天，发现灰度机的ygc变的非常平稳，时间降到了 10ms左右，gc的log如下:
结论
因为容器不是物理隔离的，部署的java应用，务必要指定-XX:ParallelGCThreads=CPU_COUNT ，以防被YGC被坑了。
原文链接
https://juejin.im/post/5b63ff20e51d4519946020b1