【Java核心-性能基础】JVM 对代码执行的优化

 

1. JVM 对代码执行的两类优化

1.1 运行时优化

主要是针对解释执行和动态编译的一些通用机制的优化。如，锁（包括偏斜锁）和内存分配（如 TLAB）。

还包括一些专门优化解释执行效率的机制。如，模板解释器、内联缓存（优化虚方法调用的动态绑定）。

 

1.2 JIT优化

JVM根据运行时统计信息（Profile），动态决定部分方法（热点代码）被编译成机器码，直接运行在底层硬件上。

JIT 编译器的技术有 方法计数器、循环展开（Loop unrolling）、方法内联、无效代码消除（Dead Code Elimination）、逃逸分析、分支预测（Branch Prediction）等

这些编译所得的机器码会被暂存于Code Cache。

因为Code Cache容量有限，所以当热点代码不再是热点时，其对应的本地代码会被从Code Cache中移除。这就是 逆优化。

 

 

 

 

栈上替换技术（OSR，On-Stack Replacement）

针对热点循环代码，如果方法本身的调用频度还未达到编译标准，但是内部有大的循环，那么该方法还是会被判定为有优化价值而被编译。

 

2. 探查JVM优化的具体情况

针对Java编译期优化，我们可以通过反编译工具查看被优化的细节（如，常量折叠）

针对JVM运行期间的优化，我们一般通过设置启动参数让JVM输出相关日志，或一些专门的监控工具来查看相关细节。（《JVM内存监控与诊断》）

 

2.1 打印编译发生的细节

-XX:+PrintCompilation

 

输出更多编译细节：

-XX:UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:LogFile=<your_file_path>

可通过 JitWatch 查看日志文件。（分析指南） 

 

2.2 打印内联发生的细节

-XX:PrintInlining

 

2.3 查看 Code Cache 的使用情况

JMC、JConsole等工具

 

3. JVM 代码执行优化的调优角度和手段

3.1 调整热点代码门限值

-XX:CompileThreshold=N

通常是降低该值，以降低预热时间。

server模式默认10000次，client模式默认1500次

此外，JVM 会周期性的对方法计数的数值进行衰减，从而导致某些代码永远都达不到默认的热点代码门限值。所以降低降低该门限值可以让这些代码有机会成为热点。

当然也可以关闭计数衰减 -XX:-UseCounterDecay

 

3.2 调整 Code Cache 大小

-XX:ReservedCodeCacheSize=<SIZE>

通常是增大其容量，以容纳更多编译后的代码。

调整其初始容量：

-XX:InitialCodeCacheSize=<SIZE>

 

3.3 调整编译器线程数，或选择适当的编译器模式

JVM的编译器线程数与JVM的模式有关。

client模式默认只有一个编译线程（C1，Client Compiler）

server模式默认是两个（C2，Sever Compiler）

HotSpot 默认启用了分层编译（Tiered-Compilation），JVM会根据CPU内核数计算C1 和 C2 的数值。

可以通过启动参数指定编译线程数。-XX:CICompilerCount=N

 

如果CPU核数多资源足，可以增大编译线程数，以充分利用资源，加快相关优化执行过程。

如果CPU资源少，或系统中有多个应用在争抢资源，则可以考虑减少编译线程数，降低线程切换的开销。

但是，通常可以在服务器上关闭分层编译（-XX:-TieredCompilation）。虽然预热速度稍慢，但省下的CPU资源可能提高某些业务场景的吞吐量。

“优化”没那么高大上，就怕瞎捣腾，毫无章法地胡乱设置一通浪费时间。

其实JVM已经优秀到足以应付绝大多数场景了。通常都无需这么冷门艰涩的调优手段。

性能差往往是因为业务代码本身有逻辑硬伤，或是服务器性能（包括网络环境）真的不行。

绝大多数Java项目组织根本没资格在这个层面拼优化，做好需求、设计和工程管理就已经有资格评优了。