核心内容摘要
探寻“日日撸”的隐秘花园：从指尖到心灵的奇妙旅程
今天讲的 JVM 字节码执行方式是 HotSpot 虚拟机最核心的性能设计之一 ——解释执行主打轻量启动JIT 编译执行聚焦运行性能而 HotSpot 并非二选一而是采用「解释执行 JIT 编译」的混合执行模式结合两者优势实现 “启动快、运行快” 的效果。
其中解释执行是逐行翻译字节码的 “即时翻译模式”JIT 编译则是对高频执行的热点代码提前编译为机器码的 “预编译模式”HotSpot 内置的 C
C2 编译器又针对不同场景做了分层优化分别适配客户端轻量场景和服务端高性能场景。
读懂这两种执行方式的分工、协作逻辑以及 C1/C2 的差异你就能理解 JVM 为何能兼顾启动速度和运行性能还能通过 JVM 参数调优适配不同业务场景。
HotSpot 的最优解首先要明确一个核心点现代 HotSpot 虚拟机JDK
7默认采用「解释执行 JIT 编译」的混合执行模式而非单纯的解释执行或编译执行。
这个设计的底层逻辑是弥补两种方式的短板、发挥优势程序启动阶段用解释执行无需提前编译逐行翻译字节码即可运行保证启动速度快适合微服务、命令行工具等对启动耗时敏感的场景程序运行阶段通过热点探测识别高频执行的代码由 JIT 编译器后台编译为本地机器码后续直接执行机器码避免重复翻译字节码保证运行执行快适合后台服务、大数据计算等对运行性能要求高的场景。
简单说解释执行负责 “快速启动”JIT 编译负责 “长期高性能运行”两者在程序生命周期中协同工作。
而你提到的 C
C2 编译器是 HotSpot 为 JIT 编译设计的分层编译器分别在运行不同阶段介入进一步优化 “编译速度” 和 “编译后性能” 的平衡。
解释执行解释执行是 JVM 最基础的执行方式核心完全匹配你提到的逐行翻译字节码启动快、执行慢其本质是 JVM 的字节码解释器充当 “翻译官”将 Java 字节码逐行翻译为对应平台的本地机器码翻译一行、执行一行无任何提前编译和缓存逻辑。
核心执行原理字节码执行引擎加载方法的字节码指令流如iload_
iadd、ireturn解释器按程序执行顺序逐行将字节码指令翻译为当前 CPU 能识别的本地机器码如 x86/ARM 指令翻译完成后立即交给 CPU 执行执行完下一行字节码时重复 “翻译→执行” 流程无任何缓存同一段字节码每次执行都要重新翻译。
核心优缺点优点缺点启动速度极快无需编译步骤加载字节码即可逐行执行无额外资源消耗执行速度慢重复执行的代码会被反复翻译存在大量冗余工作资源占用低无需开辟内存存储编译后的机器码适合内存受限场景无优化空间逐行翻译仅保证正确性无法对代码做性能优化跨平台性好解释器做了平台适配同一字节码可在不同 CPU / 系统上翻译执行-
适用场景解释执行主要用于程序启动初期或冷代码执行执行次数极少的代码典型场景微服务应用启动阶段快速加载并运行服务缩短启动耗时命令行工具如java -jar xxx.jar执行单次任务全程执行代码量少无需编译优化内存受限的嵌入式设备避免 JIT 编译的内存开销。
解释器的进化HotSpot 的解释器并非单一实现JDK
8 后默认使用模板解释器为每个字节码指令提前编写好对应的机器码模板翻译时直接复用模板相比早期的 “纯解释器”逐行拼接机器码大幅提升了翻译效率。
编译执行JITJITJust-In-Time即时编译是 HotSpot 提升运行性能的核心核心匹配你提到的热点代码编译为本地代码执行快其本质是JVM 在运行时通过热点探测找到高频执行的代码由 JIT 编译器在后台将其编译为优化后的本地机器码并缓存到代码缓存区后续该代码执行时直接跳过解释执行执行编译后的机器码。
核心前提JIT 编译的前提是识别热点代码—— 即执行次数足够多、值得为其编译优化的代码HotSpot 主要识别两类热点代码热点方法被多次调用的方法如循环中的调用方法、服务核心业务方法热点循环方法内的多次执行的循环体如for/while循环即使方法仅调用一次循环体执行次数多也会被标记为热点。
核心步骤JIT 编译是一个后台异步执行的过程不阻塞主线程执行完整流程flowchart TD A[程序以解释执行启动] -- B[JVM开启热点探测为代码设置计数器] B -- C{代码执行时计数器累加} C -- 未达热点阈值 -- D[继续解释执行] C -- 达到热点阈值 -- E[标记为热点代码触发JIT编译] E -- F[JIT编译器在后台编译热点代码为优化后的机器码缓存到代码缓存区] F -- G{后续代码执行} G -- 解释执行中 -- H[切换为直接执行编译后的机器码] G -- 首次执行 -- I[直接执行机器码] I -- J[执行效率提升5~10倍] H -- J关键环节HotSpot 通过两个计数器判断是否为热点代码计数器阈值可通过 JVM 参数调整默认值随 JVM 版本 / 模式变化方法调用计数器统计方法被调用的次数适用于识别「热点方法」回边计数器统计循环体执行的次数字节码中goto等跳转指令的回边次数适用于识别「热点循环」。
当任意一个计数器达到热点阈值该代码就会被标记为热点触发 JIT 编译。
核心优势执行速度极快编译后的机器码可直接被 CPU 执行无需解释翻译相比解释执行性能提升5~10 倍甚至更高支持深度优化JIT 编译器会对热点代码做多种底层性能优化如逃逸分析、标量替换、循环展开、方法内联进一步提升执行效率后台异步编译编译过程在后台线程执行不阻塞主线程保证程序运行不中断缓存复用编译后的机器码缓存到代码缓存区后续执行直接复用无重复编译开销。
核心缺点启动阶段无优化需等待热点代码出现后才会编译启动初期仍依赖解释执行占用额外内存代码缓存区需要存储编译后的机器码若热点代码过多可能导致代码缓存区溢出编译有开销JIT 编译需要消耗 CPU 和内存资源简单代码的编译开销可能超过执行收益因此需设置热点阈值避免过度编译。
HotSpot 的两大 JIT 编译器你提到的 C
C2 是 HotSpot 内置的两款 JIT 编译器设计目标完全不同分别适配客户端Client和服务端Server场景JDK
7 后引入分层编译将两者结合发挥各自优势。
1C1 编译器轻量编译快速产出别称客户端编译器Client Compiler设计目标快速完成编译以最小的编译开销产出可用的优化机器码兼顾 “编译速度” 和 “执行性能”编译策略轻量级优化仅做简单的性能优化如方法内联、常量折叠、局部变量优化编译耗时短资源占用低适用场景程序运行初期的热点代码编译、客户端应用如桌面程序、对启动速度要求高的微服务触发时机热点代码首次达到阈值时由 C1 先快速编译保证代码尽快从解释执行切换为编译执行。
2C2 编译器重量级编译极致优化别称服务端编译器Server Compiler设计目标极致的执行性能以较高的编译开销产出高度优化的机器码适合长期运行的程序编译策略深度重量级优化做复杂的底层优化如逃逸分析、标量替换、循环展开 / 重排序、锁消除甚至会根据 CPU 架构做针对性优化编译耗时较长但编译后执行性能极致适用场景程序运行后期的热点代码重编译、服务端应用如后台接口、大数据计算、长期运行的守护进程触发时机C1 编译后的代码若继续高频执行计数器再次达到更高阈值C2 会在后台对其做重编译替换为更优化的机器码。
3C1 vs C2特性C1 编译器ClientC2 编译器Server设计目标快速编译低开销极致性能高优化优化程度轻量级优化简单重量级优化深度编译速度快毫秒级慢百毫秒 / 秒级编译后性能中等比解释执行快 5~8 倍极高比解释执行快 10~20 倍资源占用低CPU / 内存高CPU / 内存适用阶段程序运行初期程序运行后期适用场景客户端、微服务启动服务端、长期运行应用
关键优化JDK
7 后 HotSpot 默认开启分层编译参数-XX:TieredCompilation将 C1 和 C2 结合实现 “启动快、运行快、全程高性能”这也是目前生产环境的默认模式。
分层编译将代码执行分为5 个层级核心是前 4 层从解释执行逐步升级到 C2 的极致优化第 0 层纯解释执行无编译启动初期的默认方式第 1 层C1 轻量编译简单优化热点代码首次触发编译时的层级快速切换为编译执行第 2 层C1 中等优化比第 1 层多部分优化针对执行次数更高的代码第 3 层C1 全量优化C1 的最高优化级别接近 C2 的编译效果编译耗时比 C2 短第 4 层C2 重量级编译极致优化针对长期高频执行的核心代码最终性能最优。
分层编译的核心逻辑热点代码从低层级逐步升级到高层级先由 C1 快速承接保证运行性能快速提升再由 C2 后台深度优化实现极致性能既避免了 C2 编译慢的问题又发挥了其优化优势。
HotSpot 混合执行模式结合解释执行、C
C2 和分层编译梳理 HotSpot 从启动到稳定运行的完整执行流程让你理解两者的协同逻辑启动阶段第 0 层JVM 加载字节码以纯解释执行运行程序无任何编译开销保证启动速度预热阶段第 1~3 层JVM 开启热点探测计数器累加当代码达到热点阈值触发C1 编译器后台轻量编译代码执行层级升级到第 1 层从解释执行切换为 C1 编译执行性能快速提升若代码继续高频执行层级逐步升级到第
3 层C1 做更全面的优化性能进一步提升稳定运行阶段第 4 层核心业务代码长期高频执行计数器达到 C2 触发阈值触发C2 编译器后台重量级编译将代码重编译为极致优化的机器码层级升级到第 4 层后续该代码永久执行 C2 编译后的机器码实现最优运行性能全程异步所有 JIT 编译C1/C2均在后台线程执行不阻塞主线程程序运行无感知。
常用 JVM 参数针对解释执行和 JIT 编译整理生产环境常用的 JVM 调优参数适配不同业务场景核心围绕 “热点阈值”“编译器选择”“代码缓存区” 展开
编译器基础配置-XX:UseJITCompiler开启 JIT 编译JDK
8 默认开启关闭用-XX:-UseJITCompiler纯解释执行-XX:TieredCompilation开启分层编译JDK
7 默认开启关闭用-XX:-TieredCompilation仅用指定编译器-XX:CompileThreshold设置热点代码的基础阈值方法调用计数器默认值Client 模式 1500Server 模式 10000-XX:CICompilerCount设置 JIT 编译线程数建议值CPU 核心数 / 2避免编译线程过多占用 CPU。
编译器选择关闭分层编译时使用-client强制使用 C1 编译器Client 模式轻量编译-server强制使用 C2 编译器Server 模式深度编译JDK
864 位默认。
代码缓存区配置避免溢出JIT 编译后的机器码存储在代码缓存区若热点代码过多会导致缓存区溢出触发OutOfMemoryError: CodeCache需合理配置-XX:InitialCodeCacheSize设置代码缓存区初始大小如64m-XX:ReservedCodeCacheSize设置代码缓存区最大大小如256m服务端建议至少 256m-XX:UseCodeCacheFlushing开启代码缓存区刷新当缓存区不足时回收未使用的编译代码。
场景化调优示例微服务启动快优先-XX:CompileThreshold500 -XX:CICompilerCount2→ 降低热点阈值让 C1 更快编译减少编译线程数降低启动开销后台服务性能优先-XX:ReservedCodeCacheSize512m -XX:CICompilerCount4→ 扩大代码缓存区增加编译线程数让 C2 更充分地优化核心代码嵌入式设备资源受限-XX:-UseJITCompiler→ 关闭 JIT 编译纯解释执行节省内存和 CPU。
IT 编译的
常见问题代码缓存区溢出表现为OutOfMemoryError: CodeCache原因是热点代码过多或缓存区设置过小解决增大ReservedCodeCacheSize开启UseCodeCacheFlushing预热不足导致性能抖动服务启动后直接压测因热点代码未完成 JIT 编译性能波动大解决做服务预热启动后先执行少量请求触发 JIT 编译过度编译消耗资源简单代码如工具类方法被频繁编译编译开销超过执行收益解决提高CompileThreshold阈值避免低频率代码被编译JIT 优化失效某些代码写法会导致 JIT 无法优化如反射调用、动态代理解决尽量避免在热点代码中使用反射或使用 JDK8 的MethodHandle替代反射。
最后小结核心回顾HotSpot 采用 **「解释执行 JIT 编译」的混合执行模式 **核心是 “启动用解释执行运行用 JIT 编译”兼顾启动速度和运行性能解释执行逐行翻译字节码启动快、执行慢无优化适用于程序启动初期和冷代码JIT 编译执行对热点代码高频方法 / 循环后台编译为本地机器码执行快支持优化核心是热点探测计数器机器码缓存HotSpot 内置两款 JIT 编译器分工明确C1Client轻量编译速度快、优化浅适用于运行初期快速提升性能C2Server重量级编译速度慢、优化深适用于运行后期实现极致性能分层编译默认开启将 C1 和 C2 结合代码执行从解释执行逐步升级到 C2 编译执行实现全程高性能。