Java方法内联是HotSpot JVM的JIT编译器在运行时对热点方法做的优化，将小方法字节码复制到调用处以消除调用开销，但受大小、虚调用、同步块等限制，需通过JIT日志而非字节码确认。
Java方法内联是JIT编译器干的，不是你写的代码决定的
方法内联不是Java语言特性，也不是@Inline注解（这玩意儿根本不存在），而是HotSpot JVM在运行时由JIT编译器自动做的优化。它把小方法的字节码“复制粘贴”到调用处，省掉一次方法调用的栈帧开销——但前提是JIT认为值得这么做。
常见错误现象：javap -c看字节码里仍有invokevirtual指令，就以为没内联；其实字节码层面永远有调用指令，内联发生在JIT编译后的本地机器码里，字节码不变。
- JIT只对热点方法（被频繁执行的方法）做内联，冷方法永远不会被内联
- 方法体太大（默认阈值约325字节）、含虚方法调用、递归、synchronized块，都会让JIT放弃内联
-
-XX:MaxInlineSize=和-XX:FreqInlineSize=可调阈值，但乱调容易适得其反
怎么确认某个方法到底有没有被内联
靠猜没用，得看JIT日志。开启-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -XX:+LogCompilation，再配合hsdis插件看汇编码，才是唯一靠谱方式。
典型日志片段：inline (hot) java.lang.String::length @ bci 2 表示成功内联；too big或hot method too big说明超了大小阈值；not inlineable可能是含异常处理或反射调用。
立即学习“Java免费学习笔记（深入）”；
- 别信
System.nanoTime()前后测性能来“验证”内联——微基准测试受太多干扰，结果不可靠 - 用
jmh写基准测试时，确保方法足够热（预热充分），否则JIT根本没机会介入 -
-XX:+PrintOptoAssembly能打印最终汇编，但输出极长，只建议定位关键路径
哪些写法会让JIT更愿意内联
不是越短越好，而是越“可预测”越好。JIT喜欢确定性：确定的调用目标、确定的控制流、确定的返回值类型。
- 优先用
final类、private或static方法——避免虚方法表查找开销 - 避免在小方法里throw新异常（
new RuntimeException()会阻止内联） - 减少分支数量，尤其是
if嵌套过深或含instanceof检查 - 不要为了“看起来能内联”而强行拆分逻辑——JIT对连续小方法链（如a→b→c）也能做链式内联，但前提是每层都满足条件
内联不是万能的，有时反而有害
过度内联会让生成的机器码体积暴涨，挤占CPU指令缓存（i-cache），反而降低整体吞吐。尤其在方法体虽小但调用点极多时，复制几十份相同逻辑可能比一次跳转更慢。
- 对GC敏感的场景（如大量短生命周期对象创建），内联后方法变大，可能延迟JIT编译时机，导致更多对象进入老年代
- 使用
invokedynamic（Lambda、方法引用）时，JIT内联策略更保守，因为目标方法在运行时才绑定 - 模块化（JPMS）下跨模块的public方法，即使很小，JIT也可能因封装限制而不内联
真正难的不是让JIT内联，而是理解它为什么没内联——那通常暴露的是你代码里隐藏的不确定性，比如隐式装箱、异常路径、或不经意的多态调用。
