Java JIT对不含this引用的static方法内联最放心，因其调用目标确定、无虚分派、无对象状态依赖；验证需用-XX:+PrintInlining查看日志，而非仅看字节码。
Java JIT 对 不含 this 引用的 static 方法 的内联优化，本质上是它最“放心”也最常执行的一类内联——因为这类方法天然满足内联的核心前提：调用目标确定、无虚分派、无对象状态依赖。分析它，关键不是“能不能”，而是“为什么能”以及“是否真的发生了”。
为什么 static 方法天然适合内联
static 方法不依赖实例状态，没有 this，也就不存在多态分派（virtual dispatch）；JIT 无需做类层次分析（CHA）来确认重写情况，调用目标在编译期即可静态绑定。加上其常见于工具类、数学计算、纯函数式逻辑（如 Math.abs()、Objects.requireNonNull()），JIT 会优先将其纳入内联候选。
- 调用指令为
invokestatic，比invokevirtual更易建模控制流 - 无锁、无异常处理、无字段访问时，CFG（控制流图）极简，C1 编译器阶段就可能完成内联
- 若方法体小（默认 ≤35 字节码）、无同步块、无 try-finally，几乎必然被内联
验证内联是否实际发生
不能靠看源码或 javap -c 输出判断——字节码里永远显示 invokestatic。唯一可靠方式是启用 JIT 内联日志：
- 启动参数：
-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining - 运行后搜索日志中类似
inline (hot) java.util.Objects.requireNonNull(java.lang.Object)的行，带(hot)表示成功内联 - 若看到
too big或has synchronized，说明虽是 static，但因体积超限或含同步块被拒
识别影响内联的关键干扰项
即使声明为 static，也不代表一定被内联。以下因素会显著降低成功率：
立即学习“Java免费学习笔记（深入）”；
-
方法体含 synchronized 块：monitorenter/monitorexit 破坏控制流线性，JIT 日志常提示
has monitor - 嵌套异常处理：try-catch 与 static 方法共存时，异常表增加 CFG 复杂度，C1 阶段极易放弃
-
返回值或参数涉及逃逸对象：如 static 方法返回新创建的
ArrayList，且该对象被外部持有，JIT 可能因逃逸分析未收敛而延迟或跳过内联 -
字节码过大或含大量分支：超过
-XX:MaxInlineSize默认阈值（35），或内联后导致热点代码膨胀，触发 L1 指令缓存压力
提升内联概率的实操建议
目标不是让所有 static 方法都内联，而是让高频调用的纯计算逻辑“被 JIT 看见并信任”：
- 将复杂逻辑拆解为多个小的、无副作用的
private static final方法——final 进一步消除重写疑虑 - 避免在 static 方法内部 new 对象或调用非内联友好的 API（如
String.format()） - 对性能敏感路径，用
-XX:+PrintCompilation确认该方法是否已升为 C2 编译级别（C2 比 C1 更激进，支持更大方法内联） - 必要时微调阈值，如
-XX:MaxInlineSize=45，但需配合-XX:+PrintCodeCache监控代码缓存使用率，防止溢出
