Java JIT内联是基于热点判定和类型推测的动态优化，要求方法足够热且调用目标稳定（单态/静态/唯一接口实现），受深度（MaxInlineLevel=9）、递归（MaxRecursiveInlineLevel=1）、大小（FreqInlineSize=325等）多重限制，失败常见于@DontInline、caller未编译、符号未解析或synchronized锁不可推断等情况。
Java的即时编译器（JIT，主要是HotSpot的C2编译器）会在运行时对热点方法进行内联（inlining），这是提升性能最关键的优化之一。内联不是简单地把方法体“复制粘贴”，而是综合调用频率、方法大小、字节码复杂度、类型信息等多因素动态决策的结果。是否内联、何时内联、内联多深，都受严格限制。
触发内联的核心条件：方法必须是“热点”且“可推测”
内联不会在方法第一次执行时发生，而是等待JIT判定该方法足够“热”——即被频繁调用（默认阈值：client模式1500次，server模式10000次，可通过-XX:CompileThreshold调整）。更重要的是，JIT需要能**稳定推测调用目标**：
- 单态调用（monomorphic）：某个虚方法调用点上，99%以上时间只命中同一个具体子类实现（通过类型Profile数据判断）；此时C2会生成带类型检查的快速路径+去优化兜底
- 完全静态方法（static/final/private/构造器）：无需类型检查，直接内联
- 接口方法若能唯一绑定到一个实现类（如仅有一个非default实现），也可能内联
内联深度与嵌套限制：防止代码爆炸
过度内联会导致机器码急剧膨胀，反而降低指令缓存效率。HotSpot通过多层阈值控制嵌套深度：
- -XX:MaxInlineLevel=9：方法直接调用链的最大深度（main → a → b → …，最多9层）
- -XX:MaxRecursiveInlineLevel=1：递归调用默认只内联第一层（如f()调用自身，第二层起不内联）
- 被调用方若已内联过其他方法，剩余“额度”会扣减，避免雪球效应
方法体大小限制：字节码长度与复杂度双重约束
JIT不用源码行数判断，而看字节码指令数（BCI）和控制流复杂度：
立即学习“Java免费学习笔记（深入）”；
- 默认“小方法”阈值：-XX:FreqInlineSize=325（C2编译的热点方法，字节码≤325才考虑内联）
- 普通方法阈值：-XX:MaxInlineSize=35（非热点但被高频调用的方法，上限更严）
- 含大量分支、异常处理块、大switch或循环的方法，即使短也可能被拒绝（C2会估算内联后IR节点增长）
常见导致内联失败的情况
即使方法很短，以下情况也会让JIT放弃内联：
- 方法被标记为@DontInline（JDK内部调试用）或@ForceInline（需配合-XX:+UnlockDiagnosticVMOptions）
- 调用点所在方法尚未被编译（caller未达热点，callee再热也不内联）
- 存在未解析的符号引用（如类正在加载中、类加载失败后残留的invokedynamic call site）
- 方法体含synchronized块且锁对象不可静态推断（C2难以安全消除锁，倾向不内联）
基本上就这些。内联是JIT最“智能”也最“保守”的优化之一——它宁可少内联，也不愿因推测失败频繁去优化（deoptimization）。用-XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions可查看每次内联决策的日志，比死记参数更有价值。
