JVM系列(八) -运行期的几种优化技术

志哥聊技术

于 2024-09-05 17:01:17 发布

阅读量447

点赞数 4

分类专栏： java 虚拟机文章标签： jvm 开发语言 java

本文链接：https://blog.csdn.net/dxflqm_pz/article/details/141935731

版权

一、摘要

在之前的文章中我们谈到过，相比 C/C++ 语言，Java 语言在运行效率方面要稍逊一些，因为 Java 应用程序是在虚拟机上运行，而 C/C++ 程序是直接编译成平台相应的机器码来运行程序。

从虚拟机对外发布开始，开发团队一直在努力试图缩小 Java 与 C/C++ 语言在运行效率上的差距。从实际的结果来看，确实成果显著。

本文就来聊聊 HotSpot 虚拟机为了提升 Java 程序的执行效率，都实现了哪些激动人心的优化技术。

二、JIT 编译器的引入

JIT 编译器，也称为即时编译器，它是 JVM 的重要组成部分。与我们经常用的生成 Java 字节码的javac编译器不同，JIT 编译器是实现 Java 程序执行效率提升的核心利器。

经常有面试官会提出这样的一个问题：Java 程序是解释执行还是编译执行？

刚开始学习 Java 的同学，大概率会认为 Java 是编译执行，其执行流程类似于如下图。

源码程序.java文件，通过javac命令编译成.class字节码，最后通过java命令在虚拟机中利用解释器来执行代码。其中虚拟机的解释器作用，就是将字节码的操作指令和真正的平台体系之间的指令建立映射，比如把 Java 的load指令转换成native code的load指令，以此来完成程序的执行。

其实，准确的说，Java 既有解释执行，也有编译执行，其工作流程大致可以用如下图来描述。

其中，JIT 编译器会将热点代码编译成本地平台相关的机器码，并进行各种层次的优化，从而实现程序执行效率的提升。

JIT 编译器的出现，可以说补强了虚拟机边运行边解释的低性能问题。

也许有的同学会提出这样的疑问，既然引入了 JIT 编译器可以显著提升程序执行效率，那 HotSpot 为什么不直接采用 JIT 编译器来执行呢？

简单的说，解释器和编译器各有优势。

当程序需要迅速启动和执行时，解释器可以首先发挥作用，省去编译的时间，可以立即执行
当程序运行后，随着时间的推移，JIT 编译器可以发挥作用，能把越来越多的代码编译成本地机器码，进一步提升程序的执行效率

这就是为什么 Java 程序既有解释执行，也有编译执行的原因。

当然，能触发即时编译请求的条件比较多，比如方法调用，OSR 编译请求等。在默认设置下，无论是哪种场景，虚拟机在代码编译器还未完成的时候，都仍然按照解释器来继续执行，而编译动作则是在后台的编译线程中运行。

用户可以通过-XX:-BackgroundCompilation参数来禁止后台编译，此时所有的编译请求会等待，直到编译完成后再开始执行本地机器码。

2.1、Client 模式与 Server 模式

在 HotSpot 虚拟机中内置了两款即时编译器，分别是Client Compiler和Server Compiler，也称为 C1 编译器与 C2 编译器。

在目前的 HotSpot 虚拟机中，默认采用的是解释器与其中一个即时编译器直接配合的工作方式，用户也可以使用-client或者-server参数来指定解释器与具体的某个编译器配合工作。

它们之间的区别，可以用如下内容简要概括：

Client Compiler（C1编译器）：它是一个简单快速的编译器，主要关注点在于局部性的优化，而放弃了许多耗时间长的全局优化手段
Sever Compiler（C2编译器）：它是专门面向服务端的典型应用并为服务端的性能配置特别调整过的编译器，它会执行所有经典的优化动作，如无用代码消除、循环展开、常量传播、基本块重排序等，还会实施一些与 Java 语言特性密切相关的优化技术，如范围检查消除、空值检查消除等，另外，还有可能根据解释器或 Client Compiler 提供的性能监控信息，进行一些不稳定的激进优化，如守护内联、分支频率预测等

Sever Compiler 即时编译器，无疑是比较缓慢的，但它的编译速度依然远超传统的静态优化编译器，而且它相对于 Client Compiler 编译器输出的代码质量更高，可以减少本地代码的执行时间，从而抵消额外的编译时间开销，因此很多非服务端的虚拟机选择-server模式来运行。