jvm调优之分层编译

最新推荐文章于 2025-02-15 11:38:44 发布

LzwGlory

最新推荐文章于 2025-02-15 11:38:44 发布

阅读量2k

点赞数

分类专栏： jvm 文章标签： jvm

jvm 专栏收录该内容

30 篇文章

订阅专栏

1 问题

最近，在某个高QPS的服务在重启的时候，如图1.1所示，重启会load 非常高，出现尖刺，短信报警CPU使用率过高，然后一段时间负载就降下来。搜索下网络的文章，启动后高负载的原因大致是由于启动，随着代码的执行，jvm的jit编译器会将部分热点代码编译为目标机器代码，这时产生的编译线程会占用大量的cpu 导致系统负载高。但是通过top -H -p 查看编译线程的cpu 使用率，发现cpu 使用率比其他线程略高，但是没有明显差距，但是比较其他的请求线程，加在一起的cpu 使用率还是很可观。所以在此怀疑，JIT编译器需要代码执行一定的频率才会进行编译优化，系统刚启动的时候大部分的代码只是解释执行，解释执行的性能比编译执行的性能当然要差很多，所以系统的负载高，等到主要热点代码都是编译执行，系统负载就降下来。那接下来如何对这个问题调优呢？

图1.1

2 jvm 调优

针对上面的问题，有两个解决方案：

2.1 纯编译执行(-Xcomp）

jvm提供了一个参数-Xcomp ,这个参数可以使jvm运行在纯编译的模式，所有的方法在第一次调用的时候就会编成机器代码，但是现实的话，设置了这个参数之后系统启动负载的确没有上升，这验证了我们之前的猜测，但是随之而来的问题，启动的时间是原来的两倍多，这对我们的应用是不好接受的，现在我们应用启动时间都快到3分钟。所以纯编译不是我们的最优选择。不过，我们还有分层编译。

2.2 分层编译（-XX:+TieredCompilation)

除了纯编译和默认的mixed之外，jvm 从jdk6u25 之后，引入了分层编译。HotSpot 内置两种编译器，分别是client启动时的c1编译器和server启动时的c2编译器，c2在将代码编译成机器代码的时候需要搜集大量的统计信息以便在编译的时候进行优化，因此编译出来的代码执行效率比较高，代价是程序启动时间比较长，而且需要执行比较长的时间，才能达到最高性能；与之相反， c1的目标是使程序尽快进入编译执行的阶段，所以在编译前需要搜集的信息比c2要少，编译速度因此提高很多，但是付出的代价是编译之后的代码执行效率比较低，但尽管如此，c1编译出来的代码在性能上比解释执行的性能已经有很大的提升，所以所谓的分层编译，就是一种折中方式，在系统执行初期，执行频率比较高的代码先被c1编译器编译，以便尽快进入编译执行，然后随着时间的推移，执行频率较高的代码再被c2编译器编译，以达到最高的性能。

3 效果

线上环境一台机器加入分层编译参数-XX:+TieredCompilation之后，如图3.1效果很明显，在大多数情况下启动之后负载都不会升高，有时候即使有会升高，也比默认的恢复快很多。