如果你观察过同一个 Java 服务在刚启动和运行半小时后的表现大概率见过一个奇怪现象同一个接口预热之后吞吐量能翻倍平均耗时却只有原来的一半。这不是玄学也不是 GC 缓存了结果而是 JVM 里的 JIT 编译器在后台默默干完了三件大事——方法内联、逃逸分析以及借助分层编译阈值决定“到底该在什么时候把手伸向代码”。这篇文章想把这套东西彻底讲清楚。我会先梳理三条优化流水线的协作关系再把方法内联、逃逸分析、分层编译阈值分别拆开聊原理、参数和失效场景最后用一个完整排查案例演示这三者怎么互相牵连。适合写过一段时间 Java、被线上性能问题虐过、又不想只靠“加参数试一试”解决问题的开发者。1. 先建立整体认知JIT优化的三条流水线是怎么协作的1.1 解释执行、C1、C2站在编译器角度重新看待Java应用Java 代码编译成字节码之后JVM 启动时并不会马上把全部字节码翻译成机器码而是先走解释执行。解释执行的优势是启动快、不挑环境但它同时背负着一个重要任务收集运行时信息。哪些方法被调得多、分支往哪边偏、某个调用点实际出现的类型是什么这套信息在 JIT 术语里叫 profiling 数据。当某个方法足够“热”JIT 编译器才会把它从字节码编译成机器码。HotSpot 里有两个分工不同的编译器C1客户端编译器编译速度快、优化相对浅适合快速响应C2服务端编译器编译慢、优化深但生成代码质量高。两者并不是互斥关系而是通过分层编译Tiered Compilation协作让方法在热度上升过程中逐步被“喂”给更激进的编译器。很多人把“Java 慢”归罪于解释执行然后把希望押在“关掉分层编译”或者“调大阈值”上。这其实没搞清楚 profiling 的养成过程。C2 要做激进优化依赖足够丰厚的运行时数据如果过早编译数据不够C2 反而会做出错误的优化假设之后还要花代价做去优化deoptimize把执行状态退回解释器。所以“预热”不是玄学是 profiling 数据从稀疏到稠密的过程。1.2 方法内联、逃逸分析、分层编译阈值为什么是一套组合拳我见过太多人把这三种优化分开理解结果排查性能问题时各查各的怎么都对不上号。实际上它们是一条链路。方法内联负责“打通调用图”把一个个小方法拼接成一个大方法的视角只有视角足够大C2 才能对对象的生命周期做全局判断也就是逃逸分析而“什么时候值得花编译成本去做这种拼接和判断”则由分层编译阈值控制。简单比喻解释执行是单个工位逐个加工零件JIT 优化是重组整条流水线方法内联相当于拆掉工位之间的隔板逃逸分析相当于判断某个零件到底需不需要堆到中央仓库堆上分层编译阈值则是“到底值不值得停机改造这条线”的决策开关。后面章节里你会反复看到这种联动。尤其是第 3 章我会讲逃逸分析为什么依赖内联结果——这是很多人栽跟头的地方。2. 方法内联收益最直接失效也最隐蔽2.1 内联到底省了什么钱方法内联做的事情不复杂把被调用方法的方法体直接“粘贴”到调用点然后让指令流直接顺序执行下去不再发生真正的 call/ret 跳转。它省下的钱分两块。第一块是机械开销栈帧的建立与销毁、参数与返回值的传递、跳转指令在 CPU 分支预测失败时的代价这些零零碎碎在单次调用中不算大但一个高频方法每秒被调用百万次时积少成多就是可观的吞吐差异。第二块更重要只有内联之后C2 才能跨方法边界做优化。比如某个 getter 返回的字段在调用后立刻被使用如果不内联调用点根本看不到 getter 内部在做什么也就无法把“对象取值”和后续计算合并成一条指令。你可以把它类比成你不希望每次查一个数据都跑到另一个房间拿一张纸而是希望直接把纸上的内容抄在眼前。但“抄”也不是无代价的——代码体积变大、指令缓存压力上升、编译时间变长。所以内联不能无脑做JIT 需要一套判定规则。2.2 内联判定的关键参数不仅仅是MaxInlineSize网上介绍内联翻来覆去就提一个-XX:MaxInlineSize实际远远不够。真正参与决策的是一组参数参数常见默认值作用-XX:MaxInlineSize35 字节普通热点方法字节码大小上限超过则不内联-XX:FreqInlineSize325 字节高频热点方法可使用更大的内联上限超过仍不内联-XX:MaxTrivialSize6 字节极小方法典型的 getter/setter的无脑内联上限-XX:MaxInlineLevel9嵌套内联的最大层数防止内联深度爆炸-XX:InlineSmallCode1000 字节被调方自身编译后机器码规模上限太大则不内联这里有几个容易误解的点。第一这里的“字节”指的是 Java 字节码的字节数不是源码行数也不是编译后机器码大小。一个看起来只有十几行的方法字节码可能已经 60、70 字节了。第二FreqInlineSize比MaxInlineSize大得多因为对被高频调用的方法C2 愿意投入更多成本去内联但对于普通热点方法35 字节的限制非常严格稍微复杂一点的方法都进不来。第三InlineSmallCode防止“巨无霸”继续膨胀。方法本身编译成机器码后已有相当规模时再把它内联到别的调用点会让调用点代码体积急剧膨胀反而损害指令缓存命中率。内联不是越多越好CPU 的一级指令缓存非常宝贵代码爆炸带来的缓存失效可能抵消所有调用开销节省。提示这些默认值在不同 JDK 版本、不同 CPU 架构下可能有差异。别把任何一张表格当真理要用下面这行命令确认当前 JDK 的真实默认值。java -XX:UnlockDiagnosticVMOptions -XX:PrintFlagsFinal -version | grep -E MaxInlineSize|FreqInlineSize|MaxTrivialSize|MaxInlineLevel|InlineSmallCode2.3 用-XX:PrintInlining做一次内联审计我在排查内联失效时第一步永远是打开内联日志。命令是java -XX:UnlockDiagnosticVMOptions -XX:PrintCompilation -XX:PrintInlining -jar your-app.jar生产环境不建议长期开压测环境或者预发环境完全可以开。日志量大建议直接落盘java -XX:UnlockDiagnosticVMOptions -XX:PrintInlining -XX:PrintCompilation -Xlog:jitinliningdebug -jar your-app.jar jit.log 21读日志时最关键的是找到你的热点方法被编译的那一行然后看它下面带了哪些调用点、每个调用点决策结果是什么。我以实际排查中常见的几种标记为例 23 com.example.OrderService::buildResult (120 bytes)表示编译OrderService.buildResult时在字节码偏移量 23 处处理某个调用点。inline (hot)内联成功且因为是高频热点方法使用了更宽松的FreqInlineSize判断。too big被调方法字节码大小超限最常见的内联失败原因。virtual call/no monomorphic caller调用点是虚方法或接口方法C2 无法确定唯一实现去虚化失败。not inlinable方法本身不可内联可能涉及同步、异常处理等复杂控制流。already compiled into a big method被调方自己已经编译成大方法不值得再内联。recursive inlining递归调用被内联了几层但受MaxInlineLevel限制。拿到这些日志后我通常先筛too big和virtual call这两个是内联失效的主要来源。筛出来之后对着热点方法的热路径一段段改代码比瞎调参数有效得多。2.4 最常见的内联失败场景与处理思路第一类是大方法。一个方法字节码超过 325 字节哪怕它被调得再热C2 也几乎不会内联。解决办法不是把FreqInlineSize调大而是拆分方法把构建、校验、默认值填充、结果映射这些步骤拆成独立小方法让热路径上的每个方法都变短。拆分后不仅更容易内联后面的逃逸分析也更容易做。第二类是虚调用和接口调用。接口方法在运行时可能有多套实现C2 需要通过类层次分析CHA判断“当前 JVM 里是否只有唯一实现”。如果只有一份实现C2 会大胆去虚化并内联但如果后续又加载了新的实现类之前基于“唯一实现”的假设就作废了C2 会把编译产物标记为made not entrant强制退回解释执行或重新编译。这就是为什么有时“加了一个类性能反而下降了”。第三类是递归调用。方法是自己调用自己理论上可以内联无限层但 JIT 会限制内联到MaxInlineLevel层内防止编译产物无限膨胀。递归深度大的代码JIT 能做的有限更应该在算法层面解决。处理这类问题时我的一般原则是先让热路径上的方法短小、单态、语义清晰再考虑调参数。参数是全局的为某个方法调大内联上限可能让代码缓存膨胀得不偿失。3. 逃逸分析别迷信“栈上分配”先理解标量替换3.1 逃逸分析判断什么不逃逸、方法逃逸、线程逃逸逃逸分析要回答的问题是一个对象在创建之后它的引用有没有“逃出”当前方法的掌控范围。HotSpot 把逃逸程度分成三档NoEscape不逃逸对象从创建到使用一直在当前方法内部没传给其他方法、没作为返回值返回、没存进静态字段或其他线程可见的容器。ArgEscape方法逃逸也叫参数逃逸对象作为参数传给了其他方法但对象本身不会继续暴露到方法之外不会返回、不会存到静态区。GlobalEscape线程逃逸对象可能被其他线程访问典型的比如存入 static 集合、ThreadLocal、发布到共享缓存等。很多人一提逃逸分析就默认“局部 new 的对象一定能优化”这是不对的。判断规则非常保守只要 C2 无法证明对象不会以某种方式暴露就一律按逃逸处理。编译器宁可放弃优化也不能产出错误结果。3.2 HotSpot 并没有真正的栈上分配它做的是标量替换很多博客说“逃逸分析后对象被分配到栈上”严格讲HotSpot 里更常见的落地技术是标量替换Scalar Replacement。标量替换的做法是把对象的所有字段拆成独立的局部变量或临时值分别存到寄存器或栈槽里new指令被整个消除对象不再在堆上占一块连续空间。没有对象自然就没有对象头、没有 GC 扫描、没有 finalizer 相关的额外开销。// 如果Point对象不逃逸C2完全可以把x、y字段当成两个局部变量来用 Point p new Point(x, y); int d p.distance();这段代码在逃逸分析生效后通常根本不会在堆上分配Point实例。注意用词不是“把对象放在了栈上”而是“对象被拆没了”。栈上分配在部分场景下也存在但标量替换才是性价比最高的形式。锁消除逻辑类似如果加锁对象没有发生线程逃逸说明锁只有单线程能看到那synchronized块的锁语义完全可以去掉进入临界区的开销直接消失。3.3 逃逸分析的致命依赖它必须先拿到内联后的调用图这是我踩过最深的坑也是本文最想强调的一点。C2 的逃逸分析不是孤立地对“当前正在编译的方法”做的而是对整个“内联后的扩展调用图”做的。为了让对象生命周期分析准确编译器必须能看到对象创建之后的所有流转路径有没有被传到别的方法有没有被存进集合有没有被返回如果关键路径上的方法没有被内联进来C2 就看不到方法体内部对对象做了什么只能保守假设它逃逸。举个例子。某个状态构造方法因为太大没被内联C2 在编译调用点时只看到“这个方法接收一个传入对象然后返回值可能被继续使用”——那就没法判断对象到底有没有逃逸于是默认它逃逸去掉标量替换该 new 的照样 new该进堆的照样进堆。所以结论很残酷方法内联一失效逃逸分析往往跟着失效。单独调整逃逸分析相关参数比如打开关闭DoEscapeAnalysis前必须先确认内联链路是通的。这也是为什么我建议排查优先级按“先查内联、再查逃逸”来走。3.4 逃逸分析失效场景与验证方法失效场景非常常见挑几个高频的对象作为方法返回值返回且调用点没有内联。返回值路径天然让对象至少达到方法逃逸级别无法标量替换。对象被放进List、Map、缓存、静态字段。这些容器大多由多个线程共享对象直接升到线程逃逸优化放弃。反射、序列化、JNI 调用。编译器无法追踪反射和框架内部的实现一律保守处理。多态调用多、分支结构过于复杂。每多一个分支就需要证明更多路径上对象都不逃逸分析精度下降最终常常全线保守。验证逃逸分析是否在工作我一般用两步。第一步打开逃逸分析日志java -XX:UnlockDiagnosticVMOptions -XX:PrintEscapeAnalysis -XX:DoEscapeAnalysis -jar your-app.jar日志里会明确标出对象是NoEscape、ArgEscape还是GlobalEscape。第二步做开关对比实验。把-XX:DoEscapeAnalysis换成-XX:-DoEscapeAnalysis关掉用 JHM 或者压测工具跑同一段逻辑对比分配量和 GC 次数。如果关掉之后分配速率暴涨、GC 次数明显上升说明逃逸分析原本是生效的如果几乎没有变化说明这段代码的对象本来就没满足逃逸条件。注意-XX:PrintEscapeAnalysis属于诊断输出必须搭配-XX:UnlockDiagnosticVMOptions使用。压测环境跑就好别直接挂生产。4. 分层编译阈值那些决定JIT“何时出手”的默认数字4.1 五层编译模型里阈值到底卡在哪几道门HotSpot 的分层编译把执行状态分成多个层次0 层是解释执行1 层是 C1 不带 profiling 的编译2、3 层是 C1 带不同粒度 profiling 的编译4 层是 C2 深度优化编译。方法热度由两组计数器描述方法调用计数器invocation counter和回边计数器backedge counter。方法每被调用一次调用计数器加一循环每回边一次回边计数器加一。计数器达到对应层的阈值后JIT 会提交编译器处理任务。分层编译的关键在于不是所有方法都要经历每一层。有的方法热度攀升很快会直接交给 C2有的方法只有循环热调用次数不高回边计数器会触发循环体级别的 OSROn-Stack Replacement编译让正在执行的解释器栈帧直接切换到编译后的机器码继续执行。4.2 值得动手调的参数与不值得动的默认值关于分层编译阈值业界讨论得非常多但真正需要手动调整的场合其实很少。我把常用参数列出来参数常见默认值参考作用-XX:TieredStopAtLevel4允许编译到的最高层设为 1 表示只用 C1-XX:CompileThreshold10000非分层模式下 C2 的调用计数阈值-XX:Tier3InvocationThreshold约 200第三层调用计数阈值-XX:Tier4InvocationThreshold约 5000第四层调用计数阈值-XX:Tier4CompileThreshold约 15000第四层编译任务综合阈值-XX:CompileThresholdScaling1.0对调用阈值做整体缩放0.5 表示整体减半-XX:CounterDecay开启解释器计数器周期性衰减这里必须强调表格里的默认值在不同 JDK 版本上有差别网上的资料很可能已经过期。最可靠的做法是启动参数里直接查java -XX:UnlockDiagnosticVMOptions -XX:PrintFlagsFinal -version | grep -E Tier|CompileThreshold|CounterDecay|InlineSize根据我自己的经验分层编译阈值最值得动的场景有两类。一类是短生命周期任务。批处理程序可能总共就跑十几秒按默认阈值C2 还没等到热度积累到 C2 层进程已经结束了。这种情况可以把-XX:TieredStopAtLevel1让 C1 快速编译虽然生成代码不如 C2 极致但至少比解释执行快得多。另一类是服务出现明显的编译尖刺。如果PrintCompilation日志显示某个时间段内大量方法被 C2 重编译甚至反复made not entrant可以尝试用-XX:CompileThresholdScaling整体抬高阈值把编译动作往后压。但这属于应急手段治本还是得看为什么会有那么多方法在反复进出编译。至于那些精确的Tier3InvocationThreshold、Tier4CompileThreshold我个人不建议日常手调。它们相互制约牵一发动全身调不好反而会让 C2 拿到质量极差的 profiling 数据。4.3 热度衰减和OSR反向阈值也很重要解释器计数器有个隐蔽特性它会随时间周期性衰减这是CounterDecay控制的。热度的本意是“近期高频调用”而不是“累计调用无限增长”。如果没有衰减一个早期被大量调用但后来冷下来的方法计数值会一直居高不下可能在未来某个时刻被无意义地重新编译。默认开启衰减的合理性就在这里。但衰减也有代价。短时高并发的流量峰值场景里如果热点方法恰好在两个衰减周期之间积累计数可能因为衰减导致计数达不到 C2 阈值C2 迟迟不出手。压测环境下我见过有人关掉衰减后 C2 表现明显更好但生产环境不建议照搬因为关掉衰减会让所有历史计数永不归零长期看反而更容易编译一堆冷方法。OSR 是另一个容易被忽略的“反向阈值”。有的方法整个生命周期只被调了几十次但每次调用都要跑百万级循环靠调用计数器根本不能说明热度。回边计数器就是专门服务循环热点的每当循环回边执行计数器累加达到阈值后 C2 会在不退出方法的前提下把当前正在执行的循环体编译并替换到运行栈上。PrintCompilation日志里方法标识前的字母n就是 OSR 编译。所以理解分层编译阈值时心里要有两条线同时跑一条是“方法被调了多少次”另一条是“循环转了多少圈”。只盯着前者永远解释不了循环密集应用的编译行为。5. 实战复盘一次GC飙升背后三个优化点接连掉链子5.1 现象加内存没用响应却越来越毛刺之前我处理过一个订单状态查询服务的问题现象非常典型。接口逻辑本身不复杂就是根据订单 ID 拉取状态记录拼装一个状态流转 DTO 返回。QPS 不算高但上线后老年代增长速度快Full GC 每几分钟一次响应耗时出现周期性的长毛刺。第一反应当然是加内存。把堆调到 4G、新生代调大问题不但没解决Full GC 频率略有下降但单次停顿时间更长了。当时 Review 代码也没发现明显问题——没有大对象没有集合缓存大部分临时对象都是接口内部创建的短期 DTO。这类问题看代码往往看不出端倪因为问题根本不在写代码的“意图”而在 JIT 优化有没有把代码意图兑现。5.2 排查用PrintCompilation和PrintInlining还原编译现场既然怀疑 JIT我在压测环境直接加了一组诊断参数java -XX:UnlockDiagnosticVMOptions -XX:PrintCompilation -XX:PrintInlining -Xlog:gc:gc.log -jar order-query-service.jar运行一段时间后查看日志第一个反常点是状态 DTO 的关键构造方法被执行了成千上万次但始终没有出现 C2 编译它的记录反而反复出现made not entrant和重新编译。顺着PrintInlining日志往下找发现调用点那一行写的是too big。换句话说热点方法虽然在被执行但 JIT 没有真正把它做深因为内联这一层先断了。热点方法的调用频率完全够但方法体的字节码超出了FreqInlineSize的容忍范围。5.3 定位逃逸分析失效才是GC压力真凶内联失败本身不会直接造成大量堆分配真正要命的是连锁反应。因为那个关键构造函数没有被内联进来C2 看不到 DTO 对象的完整流转路径逃逸分析无法证明对象不逃逸于是放弃了标量替换。后果就是接口每个请求都 new 一整批短期对象每个对象都实打实分配在堆上年轻代被快速打满对象一批批进入老年代最终变成 Full GC 的燃料。这里的问题已经不是“GC 参数不对”或者“堆不够大”而是 JIT 优化链路上游失守导致每一层后续优化都跟着失效。回头看最有价值的排查结论不是某个参数错了而是“内联→逃逸分析→GC压力”这条链路被打通后的重新认识很多 GC 问题表面看是内存问题根源却在编译优化层面。5.4 调整与验证重构方法比调阈值更有效当时我先做了一个实验性操作临时调大-XX:FreqInlineSizeGC 频率立刻降下来了说明诊断方向没判断错。但长期这么干不合理——全局放宽内联上限相当于所有热点大方法都可能被内联代码缓存膨胀、编译时间上升迟早换一种形式的性能问题。最终方案是重构方法。把那个超过 325 字节的状态构造方法拆成几个职责清晰的子方法原始数据校验、状态枚举映射、默认字段填充、最终 DTO 组装。拆完之后热路径上的每个方法都很短小PrintInlining日志里关键路径全部显示内联成功逃逸分析重新跟上大面积对象不再需要堆分配。数据验证很直观Full GC 从每几分钟一次降到几乎消失RT 毛刺消失吞吐量反而涨了。整个过程里我没怎么动分层编译阈值核心动作是“观测→定位→重构”。这也让我养成一个习惯任何性能问题先问三句话——热点方法有没有被编译内联有哪几条断了逃逸分析有没有跟着断三句话问完绝大部分 JIT 相关的坑都能定位到根因。我个人的最后一条建议是无论 JIT 资料看了多少都不如在你自己的应用里打开一次-XX:PrintCompilation和-XX:PrintInlining亲眼看一次编译现场。那些参数默认值很可能是对的真正出问题的往往是你代码结构让 JIT 无法发挥——所以遇到诡异性能问题先别急着调参先把日志开起来看清楚编译器到底在犹豫什么。