方法内联由HotSpot JIT运行时自主决策，取决于热点识别、字节码大小、调用目标确定性及同步/异常等因素；验证需用-XX:+PrintInlining查看日志，private/static/final方法因无多态风险更易内联。
方法内联不是你加个注解或改个修饰符就能立刻生效的优化手段，它完全由 HotSpot JIT 编译器在运行时自主决策。能否内联，取决于方法是否被识别为热点、字节码大小、调用目标是否可确定、是否有同步块等——你写的代码只是“候选”，JIT 才是最终拍板人。
怎么确认某个小方法是否被 JIT 内联了
靠看源码或字节码没用，javap -c 输出里永远有 invokestatic 或 invokevirtual 指令；真正能验证内联是否发生，只有启用 JIT 日志：
- 加 JVM 参数：
-XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions - 启动后搜索日志中类似
inline (hot) java.lang.Math.min(int,int)的行——带(hot)表示已内联；若看到too big或blocked by policy，说明被拒了 - 注意：
-XX:+PrintInlining只输出决策结果，不解释深层原因；想定位“为什么没 inline”，得配合-XX:+PrintOptoAssembly（需 hsdis）看汇编，但输出极长，只建议在关键路径上开
为什么 private/static/final 方法更容易被内联
JIT 做内联的前提是“调用目标确定”。public 实例方法默认是虚方法，JVM 必须在运行时查虚方法表（vtable）才能知道最终调哪个实现——这带来不确定性，而内联要求控制流和返回类型都必须可静态推断。
-
private、static、final方法没有多态风险，JIT 可直接确认唯一入口，跳过 vtable 查找 - 哪怕一个
public方法没被子类覆盖，JIT 也得先做类层次分析（CHA），证明“当前加载的所有类中无人重写它”，这个过程有开销且可能失败 - 所以对高频调用的 getter/setter 或工具方法，显式加
private或final是低成本提升内联概率的手段，比调大阈值更安全
方法体多小才算“够小”？别盲目调 -XX:MaxInlineSize
默认阈值是 35 字节码（-XX:MaxInlineSize=35），但这个数字不是越大胆越好。内联本质是用空间换时间：把方法体复制进每个调用点，会增大生成的机器码体积。
- 如果内联后导致热点循环的指令体积超出 CPU 的 L1 指令缓存（通常 32–64 KB），缓存未命中率上升，反而拖慢执行
- 看到日志里大量
too big，先检查方法是否真有必要拆那么细——比如一个 50 字节的方法，内部却含synchronized块或异常处理，JIT 会直接拒掉，调阈值也没用 - 真要调，建议从
45开始试，上限别碰100；同时监控-XX:+PrintCompilation输出，观察编译耗时和代码缓存使用率是否异常升高
内联失效的典型场景：同步块、异常处理、Lambda 引用
即使方法只有 10 行，只要包含以下任一结构，JIT 很可能放弃内联：
- 方法体内有
synchronized块：锁消除（Lock Elision）是逃逸分析阶段做的事，和内联是两套机制；带锁的方法基本不会被内联 - 方法声明了 checked exception，或内部有
try-catch（尤其是捕获非 RuntimeException）：异常表结构增加控制流复杂度，JIT 倾向保守 - 方法被 Lambda 或方法引用捕获（如
list.sort(Comparator.naturalOrder())中的 compare 方法）：此时调用是通过函数式接口间接发生的，JIT 难以在早期确定目标
这些限制不是 bug，而是 JIT 在“优化收益”和“编译稳定性”之间做的权衡。最实际的做法是：对极致性能敏感的路径，避免在小方法里塞同步、异常或函数式抽象——把逻辑收拢到一个无干扰的 private static 方法里，比纠结参数调优更有效。
