1. 一个反常识的起点Java的运行根本不是运行字节码干了这么多年Java我见过太多人把一个关键概念理解拧了很多人以为javac把.java编译成.class之后JVM就是在逐条执行字节码就像脚本语言逐行跑一样。所以当有人问我Java到底是不是编译型语言时我一般会先反问一句你觉得CPU能直接认识.class文件里的那些字节吗答案是显然不能。CPU只认机器码不认aload_0这种操作码。这里就引出了JVM执行引擎真正要干的事把字节码翻译成当前硬件平台能执行的机器码并在这个过程中做优化。字节码是JVM的指令集而不是CPU的指令集。JVM靠一套独立的栈式指令系统屏蔽了底层硬件的差异这也是一次编译到处运行能成立的根本原因——.class文件从来不是给CPU看的是给JVM这个虚拟CPU看的。那这个虚拟CPU怎么工作它就是执行引擎。JVM的整体架构可以简化成三块类加载子系统负责把.class文件加载进来运行时数据区负责分配内存、维护方法栈和堆执行引擎则负责真正干活——把字节码逐条解释或编译成当前平台能认的机器码。如果你把JVM想象成一台计算机那么执行引擎就是它的CPU字节码就是它的汇编语言而运行时数据区就是它的内存。有意思的是现代主流的HotSpot JVM并不是只走一条路而是两条腿走路解释器先跑起来保证启动速度和响应速度热点代码再被JIT编译器编译成机器码保证峰值性能。这个设计里藏着Java这么多年能在开发效率和运行性能之间取得平衡的全部秘密。这篇文章我就带你顺着这条从字节码到机器码的路径完整走一遍把执行引擎的底层机制、优化手段、观测方法一次讲透。无论你是做后端开发、准备JVM面试还是在调线上GC和CPU毛刺这篇都值得你从头读到尾。2. 字节码解剖在一个.class文件里能挖出什么2.1 class文件的骨架不止是字节码很多没深入过的同学以为.class文件里全是指令其实指令只是其中很小一部分。一个完整的class文件结构是魔数cafebabe、次版本号、主版本号、常量池、访问标志、类索引、父类索引、接口索引集合、字段表、方法表、属性表。魔数cafebabe是JVM用来识别合法class文件的暗号这个设计一直沿用到今天看了让人会心一笑——Java的创始人们确实很会整活。常量池是最大的部分里面装字面量和符号引用你可以把它理解成class文件的字典后续所有指令里的操作数、字段引用、方法引用最终都要回到这个字典里去查。方法表里才是我们熟悉的字节码指令序列。每个方法在方法表里除了有名字和描述符还有对应的Code属性这个属性里存的就是真正的字节码指令、操作数栈最大深度、局部变量表大小、异常表、行号表这些信息。所以你用javap -v看一个类时会看到方法后面跟着一长串的汇编式指令那些才是执行引擎的输入。2.2 栈式指令集 vs 寄存器指令集x86、ARM这些主流CPU用的是寄存器指令集指令形如把寄存器A和寄存器B相加结果存到寄存器C。寄存器是CPU内部的高速存储单元数量极少但访问极快。而JVM选择的是栈式指令集指令形如从操作数栈弹出两个数相加结果压回栈顶。为什么Java不直接复刻x86的寄存器模型因为跨平台。不同CPU的寄存器数量和命名都不一样如果字节码设计成依赖具体寄存器的形式那一个.class文件就不可能到处运行了。栈式指令集不依赖任何硬件寄存器JVM只需要维护一个操作数栈在任何平台上都能用统一的方式模拟。代价就是指令密度低——同样的表达式用栈式指令集需要更多条指令才能完成所以字节码执行天然比机器码啰嗦。这里有个很典型的例子。一个简单的加法a b在x86上可能一条add指令就完事但在字节码里要先aload把局部变量压栈再aload另一个再用iadd弹出两个数相加压回栈最后可能还要istore存回局部变量。你看一次加法变成了四条指令。这就决定了纯解释执行的效率天花板很低必须靠后面的JIT来救场。2.3 亲手拆一个例子i在字节码里的样子理论说多了容易晕直接看个实际的。写一个非常简单的方法public int sum(int a, int b) { return a b; }编译后用命令javap -c反编译能看到这样的输出public int sum(int, int); Code: 0: iload_1 1: iload_2 2: iadd 3: ireturn逐条解释一下iload_1把局部变量表下标为1的int型变量压入操作数栈。注意局部变量表下标0存的是this所以第1个入参a在下标1。iload_2同样的方式加载入参b。iadd从操作数栈弹出两个int相加后再压回栈。ireturn弹出栈顶的int结果作为方法返回值返回给调用方。就这么简单。但你可以从这个例子中看到栈式模型的全貌局部变量表负责取数操作数栈负责运算中转指令本身非常短小、职责单一。再扩展一下如果是int i 0; i;字节码会是0: iconst_0 1: istore_1 2: iinc 1, 1 5: return注意这里有个iinc指令它是i特有的自增指令直接在局部变量表上对下标1的变量加1不需要经过操作数栈。这种指令的存在说明字节码的设计者很务实——针对高频场景专门设计了专用指令来提高执行效率。理解了这些你后面再看JIT的优化思路就不会觉得突兀了因为JIT要解决的问题就是把这些啰嗦而规整的字节码改造成精简而跳跃的机器码。3. 解释执行第一个登场但注定不是主角的阶梯3.1 栈帧、操作数栈与局部变量表JVM执行任何一个方法都要先为它创建一个栈帧。栈帧里主要装着三样东西局部变量表、操作数栈、帧数据包括动态链接、返回地址等。局部变量表可以理解成方法的储物柜this、入参、方法内部的局部变量都按索引存在里面。它的容量在编译期就确定了所以JVM能提前为每个方法算出需要多大空间。操作数栈则是方法执行过程中的临时工作台所有字节码指令的运算中间结果都在这个工作台上流转。你去看字节码load系列指令就是从储物柜取货放到工作台store系列指令就是把工作台的结果放回储物柜。这里有个容易忽略的细节JVM并没有要求局部变量表用连续的内存单元但在主流的HotSpot实现里为了性能局部变量表用的是数组或等价结构访问速度极快。而操作数栈的压栈、弹栈操作虽然看起来是内存操作但HotSpot在解释器层面做了大量优化比如栈顶缓存Top-of-Stack Caching把操作数栈最顶部的元素直接缓存在寄存器里减少实际的内存读写。3.2 解释器为什么慢从分派机制说起早期Java被嘲讽慢得像蜗牛锅很大程度上要让解释器来背。字节码解释器的核心循环是这样的取操作码 - 查分派表 - 找到对应处理函数 - 执行 - 取下一条。这个取指-分派-执行的循环本身就有很大的开销。更关键的是每条字节码指令之间都是相互独立的解释器无法跨指令做任何全局性的优化。就拿前面那个sum方法来说四条指令各自为战解释器执行完iload_1根本不知道后面三条是同一组加法操作也就没法把这四条指令合并成x86上的一条add。这种只见树木不见森林的短视注定了性能向native看齐只能靠编译而不能靠解释。HotSpot为了解决分派开销引入了模板解释器。它的思路是不再用C函数模拟每条字节码的行为而是为每条字节码提前生成一段对应的机器码模板执行时直接跳转到模板机器码。这样一来很多常见指令的处理不再需要经过解释器主循环的分派逻辑执行效率能提升一截。但即便如此模板解释器的峰值性能依然离编译执行差了一个数量级。3.3 既然解释慢为什么不直接全量JIT这是我最常被问到的问题之一。答案很简单编译本身有成本而且成本不低。C2编译器做深度优化时需要做大量的程序分析和中间表示转换一个大型方法可能要被编译几十毫秒甚至更久。如果在应用启动时把所有方法全编译一遍启动时间会变得不可接受而且很多方法一辈子只被调用了一两次为它们花编译时间纯属浪费。解释器虽然慢但它零编译开销、随调随跑在启动阶段和冷门代码路径上反而是最优解。所以HotSpot选择了混合模式先用解释器快速跑起来通过计数器持续观察哪些方法真的被频繁调用等累积到一定热度再触发JIT编译。这也是热点这个词的由来——不是所有代码都值得编译只有成为热点的代码才配得上那昂贵的编译开销。理解了这条主线后面所有关于JIT的机制就都顺理成章了。4. 热点检测与分层编译JIT凭什么决定谁值得优化4.1 两块计数器方法调用计数与回边计数HotSpot判断一段代码是不是热点靠的是两套计数器方法调用计数器Invocation Counter和回边计数器Back Edge Counter。方法调用计数器统计的是方法被调用的次数每次方法被调用就加1当它超过-XX:CompileThreshold设定的阈值时就触发JIT编译。回边计数器统计的是方法里循环体执行的次数——注意一个方法可能总共只被调用了两次但内部有一个循环跑了一万遍这种循环才是真正的性能大户。如果只靠方法调用计数器这种低频方法里的高频循环可能永远等不到编译机会。还有个特别容易踩坑的设计计数器衰减。HotSpot在默认配置下如果方法计数器攒到一半热度、但在一段时间内没有再被调用热度就会衰减一部分。这是为了应对流量高峰过后热点转移的场景避免缓存太多过期的编译热点占用内存。但在短时压测场景下如果你只跑了很短的时间很多真正有热点潜力的方法可能还没编译就已经被衰减了下去这时候观察到的性能数据就有误导性。所以做JVM性能压测时一定要给足预热时间道理就在这。4.2 五层编译C1和C2的分工协作老版本的HotSpot有Client VM和Server VM之分分别对应C1编译器和C2编译器。C1编译速度快但优化激进程度低C2编译速度慢但优化非常深入能榨出极高的峰值性能。JDK 7引入分层编译后两者不再是非此即彼的关系而是按不同的编译层级协作。分层编译把执行状态分成了五个级别层级执行方式特点0解释执行启动最快无编译开销1C1编译无 profiling快速编译优化有限2C1编译带 profiling记录分支、类型等信息3C1完整 profiling收集足够多的运行时信息4C2编译深度优化峰值性能最强方法热度上升的过程通常是从0级开始逐级往上升最终稳定在4级。中间层级的价值在于情报收集——C1先快速编译并带着profiling运行把方法内部的分支走向、参数类型分布、是否发生多态分派等信息都记录下来然后把这些情报交给C2做深度优化。C2之所以能做出内联、逃逸分析这些激进优化很大程度上依赖这些运行时的profiling数据。这就不难理解为什么-XX:TieredStopAtLevel1这种参数会让性能明显下降——你等于把情报线人全部撤了C2根本拿不到足够的信息来精准优化。4.3 编译是异步的编译器在后台干活JIT编译不是同步阻塞在业务线程里的。HotSpot维护了一个编译队列当方法热度达到阈值后会生成一个编译任务丢进队列由后台编译线程Compiler Threads异步处理。业务线程可以继续用解释器模式或旧的编译版本跑等编译完成后再切换。编译线程的数量由-XX:CICompilerCount控制默认与CPU核数相关。这里有个容易忽略的运维细节如果机器上还有其他CPU密集型应用在抢占资源编译线程可能会被饿到导致编译排队时间变长热点方法迟迟上不了C2。线上观察方法长期停留在C1层级时除了代码本身的原因也要怀疑一下编译线程的资源竞争。另外编译任务不是一提交就能立即编译的。HotSpot对编译队列的长度有控制如果短时间内产生大量编译任务比如应用刚启动完突然进入流量高峰队列可能会被塞满有些方法会在队列里等待很久。这也是为什么很多大厂的JVM参数里会主动调大编译线程数或调整编译阈值本质就是在多做编译和少占资源之间找平衡。5. 从字节码到机器码那些看不见的魔法优化5.1 方法内联最重要且最底层的优化如果只能理解一个JIT优化手段那必须是方法内联。它的原理很简单把被调用方法的字节码直接贴进调用方的代码里从而消除方法调用本身的开销——包括压栈、弹栈、跳转、返回这些成本。但方法内联的意义远不止省掉一次调用开销。更深层的价值在于一旦被调方法的代码被内联进来它就变成了调用方法的一部分后续的寄存器分配、公共子表达式消除、死代码删除等优化就有了更大的作用域。可以这么说内联是很多其他优化的启动器没有内联后面的优化基本无从谈起。HotSpot做内联时会考虑方法大小、调用热度、是否被final修饰、是否有子类覆盖等。虚方法的多态调用是内联的大麻烦因为运行时才知道实际对象类型。HotSpot的做法是基于类层次分析CHA如果当前加载的所有类中某个虚方法只有一个实现那就可以乐观地把这个调用当成唯一实现来内联但会设置一个守护条件——如果未来有新的类加载导致这个假设被破坏就触发反优化Deoptimization回退到解释器重新执行。参数上-XX:MaxInlineSize控制可内联方法的最大字节码大小默认约35字节-XX:FreqInlineSize则针对热点方法放宽限制。实战中我见过不少性能瓶颈隐藏在一个千行大方法里、怎么调参数都没用的案例拆成小方法后性能立刻改善原因就是小方法更容易被内联优化作用于整个调用链。5.2 逃逸分析判断对象该住在新加坡还是老家逃逸分析是C2编译器里最有魔法感的优化。它分析一个新建的对象到底会不会逃逸出当前方法——如果对象只是方法内部使用没有赋值给外部对象、没有作为参数传给外部方法、没有通过返回值暴露就认为它不逃逸。不逃逸的对象能做什么最典型的是标量替换把一个对象分解成它包含的几个标量字段直接分配到寄存器或栈上而不是真的在堆里分配一块内存。比如int getSum() { Point p new Point(1, 2); return p.x p.y; }如果Point对象没有逃逸C2完全可以不new这个对象直接用两个变量或寄存器放1和2做完加法就行。对象创建、堆内存分配、GC扫描全被省掉了。很多人听说过栈上分配这个说法但我得说明白HotSpot在真实实现中主要是用标量替换来达到类似效果而不是真的在栈上分配一个完整对象。理解了这点你面试时被问到JVM到底有没有栈上分配就不会翻车了回答理论上说逃逸分析可以让不逃逸对象不经过堆分配HotSpot通过标量替换实现类似栈上分配的效果才是准确的。逃逸分析还能支撑锁消除和锁粗化。不逃逸的StringBuffer加锁可以被直接消除而循环里反复加锁的代码可以把锁的范围扩大以减少反复加解锁的开销。这些优化都很漂亮但前提都是对象不逃逸。所以写代码时尽量让对象的作用范围局部化不要动不动把临时对象塞进外部容器或全局变量这也是优化师眼里的红线。5.3 循环与边界优化你以为代码在执行其实它在被裁剪除了内联和逃逸分析C2手里还有很多剪刀。循环展开把循环体复制多份减少循环控制指令比较、跳转的执行次数。一个循环10次、每次循环体很短的方法很可能被展开成执行3次、每次处理多个迭代单元的形态。数组范围检查消除Java的数组越界检查是JVM自动做的安全机制但每个arr[i]都做边界检查是有成本的。C2会分析循环变量i的取值范围如果能证明它永远不会越界就把边界检查直接删掉。你写for (int i 0; i arr.length; i)在开启优化后i arr.length i 0这个检查大概率会被C2推断掉。这背后的逻辑是编译器对你的代码边界条件做了一次完整的数学证明证明它们不可能发生。公共子表达式消除如果两段代码都计算了同一个表达式并且中间涉及的变量没有变化C2会只算一次第二次直接用结果。比如循环内部的a.b.c这种链式字段访问只要中间没有写操作改变引用关系C2很可能会把它缓存起来复用。这些优化能力放在一起你就明白为什么我总是说别迷信底层微优化。你手写一个所谓的优化版循环可能在C2眼里根本多此一举你把代码结构写清楚、把对象生命周期控制好、把方法拆得小而内聚反而能喂给JIT更多优化空间。JVM内部的优化鼓励的是结构清晰惩罚的是过早优化。6. 亲手验证优化PrintAssembly与JITWatch实战6.1 打开编译日志看JIT到底编译了什么理论说再多不如自己看一眼。想验证JIT的工作状态第一步是用-XX:PrintCompilation打开编译日志这个参数直接往标准输出打印每次JIT编译的记录。格式类似94 35 3 com.example.BizService::handleRequest (120 bytes) 194 36 ! 4 com.example.BizService::doProcess (220 bytes)每列的含义是时间戳、编译序号、编译层级3或4、是否带有特殊标记!表示有异常处理器或synchronized等方法、方法名和字节码大小。看到方法从3级跳到4级说明分层编译在工作看到大量方法长期停留在2级或3级就要检查是不是编译线程资源不足或者方法一直被反优化。在线上诊断时-XX:PrintCompilation是可选的开路先锋因为它成本相对低。但要注意它输出量大长时间开着会有性能消耗通常是抓一小段窗口期的日志来分析。6.2 看汇编让机器码现出原形真正想看字节码变成机器码的实锤要开-XX:PrintAssembly。前提是你得先装好反汇编插件hsdis把对应的库文件放到JDK的lib/server下JVM才能把生成的机器码反汇编成可读的汇编文本。装了之后启动参数加上-XX:UnlockDiagnosticVMOptions -XX:PrintAssembly输出的内容非常庞大直接看大概率是一脸懵。更推荐的做法是用-XX:LogCompilation输出编译日志然后导入开源工具 JITWatch 可视化分析。JITWatch可以精确定位到某个方法展示它被编译的层级、内联了哪些子方法、逃逸分析的结果、甚至每条Java代码对应的汇编指令。我第一次用它在界面上看到自己的i被编译成一条addl指令时那种WOW的感觉比看十篇源码分析都来得直接。有一个强烈的建议-XX:PrintAssembly这种参数不要直接往生产环境上开输出量巨大而且可能拖慢应用。稳妥的做法是在压测环境、预发环境抓日志用同样的流量特征验证代码热点然后把结论带回生产环境的参数调优决策中。6.3 做一个内联验证小实验实践出真知我带你做一个最简单直白的内联验证实验。写两个方法public class InlineDemo { private int add(int a, int b) { return a b; } public int run() { int sum 0; for (int i 0; i 1_000_000; i) { sum add(i, i); } return sum; } }用-XX:PrintAssembly或者JITWatch看run方法的编译结果。如果C2正常起作用你会看到run方法内部直接就是循环加法的机器码根本找不到对add方法的调用指令——因为它已经被内联了add的字节码被展平进了run里。如果初始的-XX:MaxInlineSize被调得特别小、无法内联add你会发现编译出的机器码里多了一次call指令性能也相应下降。这个实验最好的部分在于它是肉眼可复现的改动一个JVM参数、重新跑一遍、对比汇编输出JIT优化的心智模型就立住了。比光看书可靠得多。微基准测试记得一定要预热先跑几轮让热点编译完成再统计耗时否则结果会被解释执行阶段的冷启动数据污染。6.4 反优化Deoptimization是什么怪物平时排查性能问题最怕看到编译日志里方法反复编译-反优化的诡异循环。反优化指C2基于假设的优化被打破后执行引擎被迫丢弃投机性的编译结果回退到解释器重新执行。典型场景就是同一个虚方法突然出现了新的实现类被加载或者某个分支的profiling信息被大量新数据推翻。反优化本身是JVM自我保护的正确机制但频繁反优化会导致CPU占用飙升、延迟毛刺。排查方式主要看编译日志中的!标记和deoptimization计数必要时结合-XX:UnlockDiagnosticVMOptions -XX:PrintDeoptimizationDetails抓细节。这类问题在高动态扩展类的框架场景里更常见普通业务代码碰到得少但一旦碰上理解执行引擎的这套信任-验证-回退机制你才不至于一头雾水。7. 回到业务侧执行引擎视角的调优与面试高频考点7.1 面试常问的执行引擎问题背后其实是一套机制JVM面试题刷过不少但很多人是死记硬背一问为什么Java不纯粹解释执行就只会说因为有JIT。实际上JIT的存在不是一句口号而是解释器的性能天花板和启动速度之间的精确权衡。同样被问什么是分层编译时如果你能讲出C1收集情报、C2消费情报做深度优化这套逻辑面试官对你JVM理解的评价会完全不一样。几个高频考点快速串一遍-Xmixed是什么混合模式即解释器和JIT共存这也是HotSpot的默认模式。纯解释模式-Xint下Java会比纯编译模式-Xcomp慢上几十倍这个对比很直观地说明了JIT的威力。为什么用-XX:TieredStopAtLevel1启动更快因为它跳过了C2编译减少了编译开销但峰值性能会下降适合在只需要短暂运行的工具类应用中用。G1和执行引擎有什么关系没有直接关系。G1是垃圾收集器管内存回收执行引擎管的是字节码执行。两者在运行时确实会互相影响比如GC停顿会影响编译线程调度但不要把垃圾回收的职责安在执行引擎头上。7.2 线上性能排查GC不是唯一的嫌疑犯很多团队排查Java应用CPU飙高第一反应永远是GC有问题一通操作猛调堆参数结果问题依旧。这时候我更建议先花几分钟看一眼编译日志方法是否长时间停留在低层级编译、是否有大量编译排队、是否出现反优化风暴。JIT异常导致的CPU开销和GC问题是完全不同的两条线混淆了就容易南辕北辙。实际操作中排查顺序我一般是这样top看CPU高的线程 -jstack抓线程栈确认是否落在GC线程还是业务线程 - 如果是业务线程再结合-XX:PrintCompilation日志确认是否有编译相关异常 - 做一轮JITWatch分析看热点方法有没有被合理内联和优化。这套组合拳打下来绝大多数隐性CPU问题都能找到方向。顺带说一句很多人在压测后发现代码明明没变换个JDK版本性能就差了很多原因往往就藏在JIT优化行为的版本差异里。JDK版本升级后C2的行为、内联阈值、逃逸分析的策略都会有细微调整直接影响同一个方法被编译成机器码的质量。所以做JDK升级评估时用PrintCompilation和JITWatch对比新旧版本的编译结果是个容易被忽略但你一定会感谢自己的好习惯。7.3 给日常开发的三条执行引擎友好建议这套机制看下来我对日常代码的建议可以浓缩成三条方法别写太大。超长方法很难被内联后续优化几乎全部失效。把一个500行的方法拆成多个内聚的小方法等于给JIT送上了优化大礼包。让对象的作用域尽量局部化。临时对象不要随随便便存进全局集合、不要从一个方法偷渡到另一个方法不逃逸的对象才能被标量替换和锁消除消灭。热点路径上避免复杂多态。频繁调用的虚方法如果总是被多个子类重写C2的内联会非常头疼。把热点路径上的类设计成final或至少让方法不带多态对性能下限是有帮助的。7.4 最后的个人体会执行引擎是JVM里最接近真实计算的部分。很多人学JVM只盯着堆、栈、GC觉得把这些搞定了就够用了但执行引擎其实决定了你的代码最终跑多快、怎么跑。每次当我打开JITWatch看到自己的多态调用被优化掉、看到循环展开生成了一串规律性的机器码都会觉得这趟从字节码到机器码的旅程值得每个Java开发者走一遍。它不会直接教你怎么调一个参数但它会改变你看Java代码的方式——你不再只看到语法和框架而能看到一段代码在JVM内部被如何对待。这种感觉就是理解底层机制带来的真正的底气。 JVM执行引擎：从字节码到机器码的优化之旅
1. 一个反常识的起点Java的运行根本不是运行字节码干了这么多年Java我见过太多人把一个关键概念理解拧了很多人以为javac把.java编译成.class之后JVM就是在逐条执行字节码就像脚本语言逐行跑一样。所以当有人问我Java到底是不是编译型语言时我一般会先反问一句你觉得CPU能直接认识.class文件里的那些字节吗答案是显然不能。CPU只认机器码不认aload_0这种操作码。这里就引出了JVM执行引擎真正要干的事把字节码翻译成当前硬件平台能执行的机器码并在这个过程中做优化。字节码是JVM的指令集而不是CPU的指令集。JVM靠一套独立的栈式指令系统屏蔽了底层硬件的差异这也是一次编译到处运行能成立的根本原因——.class文件从来不是给CPU看的是给JVM这个虚拟CPU看的。那这个虚拟CPU怎么工作它就是执行引擎。JVM的整体架构可以简化成三块类加载子系统负责把.class文件加载进来运行时数据区负责分配内存、维护方法栈和堆执行引擎则负责真正干活——把字节码逐条解释或编译成当前平台能认的机器码。如果你把JVM想象成一台计算机那么执行引擎就是它的CPU字节码就是它的汇编语言而运行时数据区就是它的内存。有意思的是现代主流的HotSpot JVM并不是只走一条路而是两条腿走路解释器先跑起来保证启动速度和响应速度热点代码再被JIT编译器编译成机器码保证峰值性能。这个设计里藏着Java这么多年能在开发效率和运行性能之间取得平衡的全部秘密。这篇文章我就带你顺着这条从字节码到机器码的路径完整走一遍把执行引擎的底层机制、优化手段、观测方法一次讲透。无论你是做后端开发、准备JVM面试还是在调线上GC和CPU毛刺这篇都值得你从头读到尾。2. 字节码解剖在一个.class文件里能挖出什么2.1 class文件的骨架不止是字节码很多没深入过的同学以为.class文件里全是指令其实指令只是其中很小一部分。一个完整的class文件结构是魔数cafebabe、次版本号、主版本号、常量池、访问标志、类索引、父类索引、接口索引集合、字段表、方法表、属性表。魔数cafebabe是JVM用来识别合法class文件的暗号这个设计一直沿用到今天看了让人会心一笑——Java的创始人们确实很会整活。常量池是最大的部分里面装字面量和符号引用你可以把它理解成class文件的字典后续所有指令里的操作数、字段引用、方法引用最终都要回到这个字典里去查。方法表里才是我们熟悉的字节码指令序列。每个方法在方法表里除了有名字和描述符还有对应的Code属性这个属性里存的就是真正的字节码指令、操作数栈最大深度、局部变量表大小、异常表、行号表这些信息。所以你用javap -v看一个类时会看到方法后面跟着一长串的汇编式指令那些才是执行引擎的输入。2.2 栈式指令集 vs 寄存器指令集x86、ARM这些主流CPU用的是寄存器指令集指令形如把寄存器A和寄存器B相加结果存到寄存器C。寄存器是CPU内部的高速存储单元数量极少但访问极快。而JVM选择的是栈式指令集指令形如从操作数栈弹出两个数相加结果压回栈顶。为什么Java不直接复刻x86的寄存器模型因为跨平台。不同CPU的寄存器数量和命名都不一样如果字节码设计成依赖具体寄存器的形式那一个.class文件就不可能到处运行了。栈式指令集不依赖任何硬件寄存器JVM只需要维护一个操作数栈在任何平台上都能用统一的方式模拟。代价就是指令密度低——同样的表达式用栈式指令集需要更多条指令才能完成所以字节码执行天然比机器码啰嗦。这里有个很典型的例子。一个简单的加法a b在x86上可能一条add指令就完事但在字节码里要先aload把局部变量压栈再aload另一个再用iadd弹出两个数相加压回栈最后可能还要istore存回局部变量。你看一次加法变成了四条指令。这就决定了纯解释执行的效率天花板很低必须靠后面的JIT来救场。2.3 亲手拆一个例子i在字节码里的样子理论说多了容易晕直接看个实际的。写一个非常简单的方法public int sum(int a, int b) { return a b; }编译后用命令javap -c反编译能看到这样的输出public int sum(int, int); Code: 0: iload_1 1: iload_2 2: iadd 3: ireturn逐条解释一下iload_1把局部变量表下标为1的int型变量压入操作数栈。注意局部变量表下标0存的是this所以第1个入参a在下标1。iload_2同样的方式加载入参b。iadd从操作数栈弹出两个int相加后再压回栈。ireturn弹出栈顶的int结果作为方法返回值返回给调用方。就这么简单。但你可以从这个例子中看到栈式模型的全貌局部变量表负责取数操作数栈负责运算中转指令本身非常短小、职责单一。再扩展一下如果是int i 0; i;字节码会是0: iconst_0 1: istore_1 2: iinc 1, 1 5: return注意这里有个iinc指令它是i特有的自增指令直接在局部变量表上对下标1的变量加1不需要经过操作数栈。这种指令的存在说明字节码的设计者很务实——针对高频场景专门设计了专用指令来提高执行效率。理解了这些你后面再看JIT的优化思路就不会觉得突兀了因为JIT要解决的问题就是把这些啰嗦而规整的字节码改造成精简而跳跃的机器码。3. 解释执行第一个登场但注定不是主角的阶梯3.1 栈帧、操作数栈与局部变量表JVM执行任何一个方法都要先为它创建一个栈帧。栈帧里主要装着三样东西局部变量表、操作数栈、帧数据包括动态链接、返回地址等。局部变量表可以理解成方法的储物柜this、入参、方法内部的局部变量都按索引存在里面。它的容量在编译期就确定了所以JVM能提前为每个方法算出需要多大空间。操作数栈则是方法执行过程中的临时工作台所有字节码指令的运算中间结果都在这个工作台上流转。你去看字节码load系列指令就是从储物柜取货放到工作台store系列指令就是把工作台的结果放回储物柜。这里有个容易忽略的细节JVM并没有要求局部变量表用连续的内存单元但在主流的HotSpot实现里为了性能局部变量表用的是数组或等价结构访问速度极快。而操作数栈的压栈、弹栈操作虽然看起来是内存操作但HotSpot在解释器层面做了大量优化比如栈顶缓存Top-of-Stack Caching把操作数栈最顶部的元素直接缓存在寄存器里减少实际的内存读写。3.2 解释器为什么慢从分派机制说起早期Java被嘲讽慢得像蜗牛锅很大程度上要让解释器来背。字节码解释器的核心循环是这样的取操作码 - 查分派表 - 找到对应处理函数 - 执行 - 取下一条。这个取指-分派-执行的循环本身就有很大的开销。更关键的是每条字节码指令之间都是相互独立的解释器无法跨指令做任何全局性的优化。就拿前面那个sum方法来说四条指令各自为战解释器执行完iload_1根本不知道后面三条是同一组加法操作也就没法把这四条指令合并成x86上的一条add。这种只见树木不见森林的短视注定了性能向native看齐只能靠编译而不能靠解释。HotSpot为了解决分派开销引入了模板解释器。它的思路是不再用C函数模拟每条字节码的行为而是为每条字节码提前生成一段对应的机器码模板执行时直接跳转到模板机器码。这样一来很多常见指令的处理不再需要经过解释器主循环的分派逻辑执行效率能提升一截。但即便如此模板解释器的峰值性能依然离编译执行差了一个数量级。3.3 既然解释慢为什么不直接全量JIT这是我最常被问到的问题之一。答案很简单编译本身有成本而且成本不低。C2编译器做深度优化时需要做大量的程序分析和中间表示转换一个大型方法可能要被编译几十毫秒甚至更久。如果在应用启动时把所有方法全编译一遍启动时间会变得不可接受而且很多方法一辈子只被调用了一两次为它们花编译时间纯属浪费。解释器虽然慢但它零编译开销、随调随跑在启动阶段和冷门代码路径上反而是最优解。所以HotSpot选择了混合模式先用解释器快速跑起来通过计数器持续观察哪些方法真的被频繁调用等累积到一定热度再触发JIT编译。这也是热点这个词的由来——不是所有代码都值得编译只有成为热点的代码才配得上那昂贵的编译开销。理解了这条主线后面所有关于JIT的机制就都顺理成章了。4. 热点检测与分层编译JIT凭什么决定谁值得优化4.1 两块计数器方法调用计数与回边计数HotSpot判断一段代码是不是热点靠的是两套计数器方法调用计数器Invocation Counter和回边计数器Back Edge Counter。方法调用计数器统计的是方法被调用的次数每次方法被调用就加1当它超过-XX:CompileThreshold设定的阈值时就触发JIT编译。回边计数器统计的是方法里循环体执行的次数——注意一个方法可能总共只被调用了两次但内部有一个循环跑了一万遍这种循环才是真正的性能大户。如果只靠方法调用计数器这种低频方法里的高频循环可能永远等不到编译机会。还有个特别容易踩坑的设计计数器衰减。HotSpot在默认配置下如果方法计数器攒到一半热度、但在一段时间内没有再被调用热度就会衰减一部分。这是为了应对流量高峰过后热点转移的场景避免缓存太多过期的编译热点占用内存。但在短时压测场景下如果你只跑了很短的时间很多真正有热点潜力的方法可能还没编译就已经被衰减了下去这时候观察到的性能数据就有误导性。所以做JVM性能压测时一定要给足预热时间道理就在这。4.2 五层编译C1和C2的分工协作老版本的HotSpot有Client VM和Server VM之分分别对应C1编译器和C2编译器。C1编译速度快但优化激进程度低C2编译速度慢但优化非常深入能榨出极高的峰值性能。JDK 7引入分层编译后两者不再是非此即彼的关系而是按不同的编译层级协作。分层编译把执行状态分成了五个级别层级执行方式特点0解释执行启动最快无编译开销1C1编译无 profiling快速编译优化有限2C1编译带 profiling记录分支、类型等信息3C1完整 profiling收集足够多的运行时信息4C2编译深度优化峰值性能最强方法热度上升的过程通常是从0级开始逐级往上升最终稳定在4级。中间层级的价值在于情报收集——C1先快速编译并带着profiling运行把方法内部的分支走向、参数类型分布、是否发生多态分派等信息都记录下来然后把这些情报交给C2做深度优化。C2之所以能做出内联、逃逸分析这些激进优化很大程度上依赖这些运行时的profiling数据。这就不难理解为什么-XX:TieredStopAtLevel1这种参数会让性能明显下降——你等于把情报线人全部撤了C2根本拿不到足够的信息来精准优化。4.3 编译是异步的编译器在后台干活JIT编译不是同步阻塞在业务线程里的。HotSpot维护了一个编译队列当方法热度达到阈值后会生成一个编译任务丢进队列由后台编译线程Compiler Threads异步处理。业务线程可以继续用解释器模式或旧的编译版本跑等编译完成后再切换。编译线程的数量由-XX:CICompilerCount控制默认与CPU核数相关。这里有个容易忽略的运维细节如果机器上还有其他CPU密集型应用在抢占资源编译线程可能会被饿到导致编译排队时间变长热点方法迟迟上不了C2。线上观察方法长期停留在C1层级时除了代码本身的原因也要怀疑一下编译线程的资源竞争。另外编译任务不是一提交就能立即编译的。HotSpot对编译队列的长度有控制如果短时间内产生大量编译任务比如应用刚启动完突然进入流量高峰队列可能会被塞满有些方法会在队列里等待很久。这也是为什么很多大厂的JVM参数里会主动调大编译线程数或调整编译阈值本质就是在多做编译和少占资源之间找平衡。5. 从字节码到机器码那些看不见的魔法优化5.1 方法内联最重要且最底层的优化如果只能理解一个JIT优化手段那必须是方法内联。它的原理很简单把被调用方法的字节码直接贴进调用方的代码里从而消除方法调用本身的开销——包括压栈、弹栈、跳转、返回这些成本。但方法内联的意义远不止省掉一次调用开销。更深层的价值在于一旦被调方法的代码被内联进来它就变成了调用方法的一部分后续的寄存器分配、公共子表达式消除、死代码删除等优化就有了更大的作用域。可以这么说内联是很多其他优化的启动器没有内联后面的优化基本无从谈起。HotSpot做内联时会考虑方法大小、调用热度、是否被final修饰、是否有子类覆盖等。虚方法的多态调用是内联的大麻烦因为运行时才知道实际对象类型。HotSpot的做法是基于类层次分析CHA如果当前加载的所有类中某个虚方法只有一个实现那就可以乐观地把这个调用当成唯一实现来内联但会设置一个守护条件——如果未来有新的类加载导致这个假设被破坏就触发反优化Deoptimization回退到解释器重新执行。参数上-XX:MaxInlineSize控制可内联方法的最大字节码大小默认约35字节-XX:FreqInlineSize则针对热点方法放宽限制。实战中我见过不少性能瓶颈隐藏在一个千行大方法里、怎么调参数都没用的案例拆成小方法后性能立刻改善原因就是小方法更容易被内联优化作用于整个调用链。5.2 逃逸分析判断对象该住在新加坡还是老家逃逸分析是C2编译器里最有魔法感的优化。它分析一个新建的对象到底会不会逃逸出当前方法——如果对象只是方法内部使用没有赋值给外部对象、没有作为参数传给外部方法、没有通过返回值暴露就认为它不逃逸。不逃逸的对象能做什么最典型的是标量替换把一个对象分解成它包含的几个标量字段直接分配到寄存器或栈上而不是真的在堆里分配一块内存。比如int getSum() { Point p new Point(1, 2); return p.x p.y; }如果Point对象没有逃逸C2完全可以不new这个对象直接用两个变量或寄存器放1和2做完加法就行。对象创建、堆内存分配、GC扫描全被省掉了。很多人听说过栈上分配这个说法但我得说明白HotSpot在真实实现中主要是用标量替换来达到类似效果而不是真的在栈上分配一个完整对象。理解了这点你面试时被问到JVM到底有没有栈上分配就不会翻车了回答理论上说逃逸分析可以让不逃逸对象不经过堆分配HotSpot通过标量替换实现类似栈上分配的效果才是准确的。逃逸分析还能支撑锁消除和锁粗化。不逃逸的StringBuffer加锁可以被直接消除而循环里反复加锁的代码可以把锁的范围扩大以减少反复加解锁的开销。这些优化都很漂亮但前提都是对象不逃逸。所以写代码时尽量让对象的作用范围局部化不要动不动把临时对象塞进外部容器或全局变量这也是优化师眼里的红线。5.3 循环与边界优化你以为代码在执行其实它在被裁剪除了内联和逃逸分析C2手里还有很多剪刀。循环展开把循环体复制多份减少循环控制指令比较、跳转的执行次数。一个循环10次、每次循环体很短的方法很可能被展开成执行3次、每次处理多个迭代单元的形态。数组范围检查消除Java的数组越界检查是JVM自动做的安全机制但每个arr[i]都做边界检查是有成本的。C2会分析循环变量i的取值范围如果能证明它永远不会越界就把边界检查直接删掉。你写for (int i 0; i arr.length; i)在开启优化后i arr.length i 0这个检查大概率会被C2推断掉。这背后的逻辑是编译器对你的代码边界条件做了一次完整的数学证明证明它们不可能发生。公共子表达式消除如果两段代码都计算了同一个表达式并且中间涉及的变量没有变化C2会只算一次第二次直接用结果。比如循环内部的a.b.c这种链式字段访问只要中间没有写操作改变引用关系C2很可能会把它缓存起来复用。这些优化能力放在一起你就明白为什么我总是说别迷信底层微优化。你手写一个所谓的优化版循环可能在C2眼里根本多此一举你把代码结构写清楚、把对象生命周期控制好、把方法拆得小而内聚反而能喂给JIT更多优化空间。JVM内部的优化鼓励的是结构清晰惩罚的是过早优化。6. 亲手验证优化PrintAssembly与JITWatch实战6.1 打开编译日志看JIT到底编译了什么理论说再多不如自己看一眼。想验证JIT的工作状态第一步是用-XX:PrintCompilation打开编译日志这个参数直接往标准输出打印每次JIT编译的记录。格式类似94 35 3 com.example.BizService::handleRequest (120 bytes) 194 36 ! 4 com.example.BizService::doProcess (220 bytes)每列的含义是时间戳、编译序号、编译层级3或4、是否带有特殊标记!表示有异常处理器或synchronized等方法、方法名和字节码大小。看到方法从3级跳到4级说明分层编译在工作看到大量方法长期停留在2级或3级就要检查是不是编译线程资源不足或者方法一直被反优化。在线上诊断时-XX:PrintCompilation是可选的开路先锋因为它成本相对低。但要注意它输出量大长时间开着会有性能消耗通常是抓一小段窗口期的日志来分析。6.2 看汇编让机器码现出原形真正想看字节码变成机器码的实锤要开-XX:PrintAssembly。前提是你得先装好反汇编插件hsdis把对应的库文件放到JDK的lib/server下JVM才能把生成的机器码反汇编成可读的汇编文本。装了之后启动参数加上-XX:UnlockDiagnosticVMOptions -XX:PrintAssembly输出的内容非常庞大直接看大概率是一脸懵。更推荐的做法是用-XX:LogCompilation输出编译日志然后导入开源工具 JITWatch 可视化分析。JITWatch可以精确定位到某个方法展示它被编译的层级、内联了哪些子方法、逃逸分析的结果、甚至每条Java代码对应的汇编指令。我第一次用它在界面上看到自己的i被编译成一条addl指令时那种WOW的感觉比看十篇源码分析都来得直接。有一个强烈的建议-XX:PrintAssembly这种参数不要直接往生产环境上开输出量巨大而且可能拖慢应用。稳妥的做法是在压测环境、预发环境抓日志用同样的流量特征验证代码热点然后把结论带回生产环境的参数调优决策中。6.3 做一个内联验证小实验实践出真知我带你做一个最简单直白的内联验证实验。写两个方法public class InlineDemo { private int add(int a, int b) { return a b; } public int run() { int sum 0; for (int i 0; i 1_000_000; i) { sum add(i, i); } return sum; } }用-XX:PrintAssembly或者JITWatch看run方法的编译结果。如果C2正常起作用你会看到run方法内部直接就是循环加法的机器码根本找不到对add方法的调用指令——因为它已经被内联了add的字节码被展平进了run里。如果初始的-XX:MaxInlineSize被调得特别小、无法内联add你会发现编译出的机器码里多了一次call指令性能也相应下降。这个实验最好的部分在于它是肉眼可复现的改动一个JVM参数、重新跑一遍、对比汇编输出JIT优化的心智模型就立住了。比光看书可靠得多。微基准测试记得一定要预热先跑几轮让热点编译完成再统计耗时否则结果会被解释执行阶段的冷启动数据污染。6.4 反优化Deoptimization是什么怪物平时排查性能问题最怕看到编译日志里方法反复编译-反优化的诡异循环。反优化指C2基于假设的优化被打破后执行引擎被迫丢弃投机性的编译结果回退到解释器重新执行。典型场景就是同一个虚方法突然出现了新的实现类被加载或者某个分支的profiling信息被大量新数据推翻。反优化本身是JVM自我保护的正确机制但频繁反优化会导致CPU占用飙升、延迟毛刺。排查方式主要看编译日志中的!标记和deoptimization计数必要时结合-XX:UnlockDiagnosticVMOptions -XX:PrintDeoptimizationDetails抓细节。这类问题在高动态扩展类的框架场景里更常见普通业务代码碰到得少但一旦碰上理解执行引擎的这套信任-验证-回退机制你才不至于一头雾水。7. 回到业务侧执行引擎视角的调优与面试高频考点7.1 面试常问的执行引擎问题背后其实是一套机制JVM面试题刷过不少但很多人是死记硬背一问为什么Java不纯粹解释执行就只会说因为有JIT。实际上JIT的存在不是一句口号而是解释器的性能天花板和启动速度之间的精确权衡。同样被问什么是分层编译时如果你能讲出C1收集情报、C2消费情报做深度优化这套逻辑面试官对你JVM理解的评价会完全不一样。几个高频考点快速串一遍-Xmixed是什么混合模式即解释器和JIT共存这也是HotSpot的默认模式。纯解释模式-Xint下Java会比纯编译模式-Xcomp慢上几十倍这个对比很直观地说明了JIT的威力。为什么用-XX:TieredStopAtLevel1启动更快因为它跳过了C2编译减少了编译开销但峰值性能会下降适合在只需要短暂运行的工具类应用中用。G1和执行引擎有什么关系没有直接关系。G1是垃圾收集器管内存回收执行引擎管的是字节码执行。两者在运行时确实会互相影响比如GC停顿会影响编译线程调度但不要把垃圾回收的职责安在执行引擎头上。7.2 线上性能排查GC不是唯一的嫌疑犯很多团队排查Java应用CPU飙高第一反应永远是GC有问题一通操作猛调堆参数结果问题依旧。这时候我更建议先花几分钟看一眼编译日志方法是否长时间停留在低层级编译、是否有大量编译排队、是否出现反优化风暴。JIT异常导致的CPU开销和GC问题是完全不同的两条线混淆了就容易南辕北辙。实际操作中排查顺序我一般是这样top看CPU高的线程 -jstack抓线程栈确认是否落在GC线程还是业务线程 - 如果是业务线程再结合-XX:PrintCompilation日志确认是否有编译相关异常 - 做一轮JITWatch分析看热点方法有没有被合理内联和优化。这套组合拳打下来绝大多数隐性CPU问题都能找到方向。顺带说一句很多人在压测后发现代码明明没变换个JDK版本性能就差了很多原因往往就藏在JIT优化行为的版本差异里。JDK版本升级后C2的行为、内联阈值、逃逸分析的策略都会有细微调整直接影响同一个方法被编译成机器码的质量。所以做JDK升级评估时用PrintCompilation和JITWatch对比新旧版本的编译结果是个容易被忽略但你一定会感谢自己的好习惯。7.3 给日常开发的三条执行引擎友好建议这套机制看下来我对日常代码的建议可以浓缩成三条方法别写太大。超长方法很难被内联后续优化几乎全部失效。把一个500行的方法拆成多个内聚的小方法等于给JIT送上了优化大礼包。让对象的作用域尽量局部化。临时对象不要随随便便存进全局集合、不要从一个方法偷渡到另一个方法不逃逸的对象才能被标量替换和锁消除消灭。热点路径上避免复杂多态。频繁调用的虚方法如果总是被多个子类重写C2的内联会非常头疼。把热点路径上的类设计成final或至少让方法不带多态对性能下限是有帮助的。7.4 最后的个人体会执行引擎是JVM里最接近真实计算的部分。很多人学JVM只盯着堆、栈、GC觉得把这些搞定了就够用了但执行引擎其实决定了你的代码最终跑多快、怎么跑。每次当我打开JITWatch看到自己的多态调用被优化掉、看到循环展开生成了一串规律性的机器码都会觉得这趟从字节码到机器码的旅程值得每个Java开发者走一遍。它不会直接教你怎么调一个参数但它会改变你看Java代码的方式——你不再只看到语法和框架而能看到一段代码在JVM内部被如何对待。这种感觉就是理解底层机制带来的真正的底气。