Contents

1. 1. 思路一，启动时候就做好C2吧
2. 2. 思路二，放弃C2吧

最近通过阿里的arthas观察到java进程经常因为”C2 CompilerThread”导致cpu使用率波动，就因为这个进程容器cpu经常彪高到告警线。
网上查的资料都感觉不靠谱，推荐方法要么用jmeter压（成本高），去尽快把代码优化成C2；要么启动多个C2进程快点完成编译（cpu更吃紧了）。
这里必须要吐槽一下JIT的机制了，对我们k8s上跑的java不友好，一般根据业务负载，我们限制单个容器500-1000m的cpu就够用了，结果不知道什么时候就来个C2把cpu搞起来，严重情况下会造成业务卡顿。。。
这里总体思路是放弃JIT编译优化，稳定为先。

思路一，启动时候就做好C2吧

java启动加上参数：-XX:-TieredCompilation， -server
这个参数是能关闭C1的level 1-3级，想当然以为跑起来就是C2优化好的。
结果：不理想，还是观察到有”C2 CompilerThread”，而且貌似cpu波动更高了。。。

思路二，放弃C2吧

java启动加上参数：-XX:TieredStopAtLevel=1
限制编译层级到level 1，虽然代码没有C2编译优化理论上运行效率打折扣，但是还是稳定优先吧。
结果：达到预期，没有观察到”C2 CompilerThread”了，cpu能稳定运行不会上蹿下跳。

JIT及编译层级参考：
Tiered Compilation in JVM
What exactly does -XX:-TieredCompilation do?
发布或重启线上服务时抖动问题解决方案