Java方法内联是JIT编译器在运行时将满足条件的热点小方法代码直接嵌入调用处以消除调用开销，需满足被频繁执行（默认10000次）、字节码≤35、无重写、无synchronized或异常块等条件，可通过-XX:+PrintInlining日志确认是否成功。
Java 方法内联是什么，它真能自动发生吗
方法内联不是你手动写的优化，而是 JIT 编译器在运行时把小方法的代码“复制粘贴”进调用处，省掉一次方法调用开销。但它不会无条件发生——HotSpot 只对满足条件的热点方法下手，比如：被反复执行（默认 10000 次）、方法体足够短（通常 ≤ 35 字节字节码）、没被重写、没含 synchronized 或异常处理块。
常见错误现象：-XX:+PrintInlining 输出里看到 hot method too big 或 not inlineable，说明 JIT 主动放弃了；不是代码写得不够好，是它根本没达到内联门槛。
怎么确认某个方法是否被内联了
靠日志，别猜。启动 JVM 时加这几个参数：
-XX:+UnlockDiagnosticVMOptions-XX:+PrintInlining-XX:+PrintCompilation
然后 grep 日志里的方法签名。例如你看到一行：inline (hot) java.lang.String::length @ bci:0，就表示成功了；如果出现 too big、too many branches 或 blocked by policy，就是被拦下了。
立即学习“Java免费学习笔记（深入）”；
注意：PrintInlining 只对 C2 编译器（server 模式）有效；用 java -client 或早期 JDK 8u 以下版本可能看不到结果。
哪些写法会悄悄破坏内联机会
看似无关的改动，可能让 JIT 直接放弃内联：
- 方法里加了个
try-catch块，哪怕里面只有一行return - 方法声明为
final但所在类是public且未被sealed，JIT 无法确定子类会不会覆盖 - 返回值是泛型类型（如
T get()），JVM 在编译期无法判断具体调用目标 - 方法体里调用了
System.out.println这类重量级方法，导致字节码膨胀超限
性能影响很实际：一个每毫秒调用上百次的 getter，如果没内联，每次多出约 5–10 纳秒的方法分派开销——累积起来就是可观的延迟毛刺。
能不能强制内联或绕过限制
不能。JVM 不提供 @ForceInline 这种东西（jdk.internal.vm.annotation.ForceInline 是内部 API，禁止在应用代码中使用，且仅限 JDK 自身模块）。
可行路径只有两条：
- 把逻辑拆得更小、更纯：去掉日志、异常包装、空检查，让方法体落在 JIT 的“舒适区”（
-XX:MaxInlineSize=35可调，但改大反而容易引发编译失败） - 用
-XX:CompileCommand=inline,MyClass::myMethod手动指令内联，但仅限调试验证，上线慎用——它会跳过所有安全检查，若方法后来被动态代理或重定义，可能 crash
真正容易被忽略的是：内联收益高度依赖调用上下文。同一个方法，在 A 类里被内联，在 B 类里可能因为调用栈深度或编译时机不同而失败。别只盯一个方法看，得看它在哪被谁怎么调。
