java方法内联由hotspot的c2编译器在运行时动态决定，依据方法热度、字节码大小（默认≤35）、是否含synchronized/异常处理器等执行特征；@forceinline对普通代码无效，虚方法需jit证明调用目标唯一才可能去虚拟化内联。
Java方法内联到底由谁决定？
不是你写的@Inline，也不是JVM启动参数直接开关——是HotSpot的C2编译器在运行时动态决定的。它看的是方法热度（调用次数）、字节码大小、是否含synchronized、是否有异常处理器等真实执行特征。你加@ForceInline（来自jdk.internal.vm.annotation）只对极少数内部API生效，普通代码无效。
- 方法体超过35字节码（默认阈值），大概率不内联；可调
-XX:MaxInlineSize=但治标不治本 - 虚方法（非final、非private、非static）默认不内联，除非JIT能证明实际调用目标唯一（比如单实现类+未被反射/动态加载干扰）
- 递归调用、包含
invokedynamic（如Lambda）、或抛出checked exception的方法，基本排除在内联候选外
怎么确认某个方法被JIT内联了？
靠日志，不是靠猜。开启-XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining -XX:+LogCompilation，然后看输出里有没有inline (hot)或didn't inline (too big)这类明确标记。注意：必须用server模式（-server已默认）、且方法要被充分预热（通常>10k次调用）才触发C2编译。
-
PrintInlining输出在控制台，关键字段是inline后面的括号内容：(hot)表示因热点触发，(callee is too large)说明超尺寸 - 如果看到
failed to inline: call site not frequent enough，说明还没进C2编译队列，继续跑几轮压测 - 不要依赖
jstack或JFR火焰图“感觉”像内联了——那些显示的是栈帧，而内联后栈帧根本不存在
虚方法调用开销真能被消除吗？
能，但条件苛刻。JIT不是靠“假设只有一个实现”，而是靠去虚拟化（devirtualization）：在类加载、链接、甚至运行时检查类继承树是否封闭。一旦发现某个接口/父类只有唯一子类被加载，且该子类没被反射修改过vtable，就敢把invokeinterface转成invokestatic或invokespecial，再走内联流程。
- 用
final修饰方法是最简单有效的信号——JIT立刻视为不可重写，无需做类型流分析 - 避免在运行时用
ClassLoader.defineClass或Unsafe.defineAnonymousClass动态注入子类，这会让JIT放弃去虚拟化判断 - 接口方法如果只被一个类实现，且该类被
java.lang.ClassLoader.getSystemClassLoader()加载（非自定义类加载器），成功率更高
内联失败时最常踩的三个坑
不是代码写得不够“优雅”，而是和JIT的认知逻辑冲突。比如把方法拆太细看似利于复用，反而让每个都卡在35字节门槛外；又比如加个无意义的try-catch，哪怕没throw，也直接让内联失效。
立即学习“Java免费学习笔记（深入）”；
- 在方法开头加空
try {} catch (Throwable t) {}——JIT认为可能改变控制流，拒绝内联 - 方法参数含
Object但实际总传String，却不声明为String——类型不稳，JIT不敢去虚拟化 - 用
StringBuilder.append(int)拼接少量固定字符串，不如直接写"a" + 1 + "b"——后者编译期优化，前者要进方法体再判断分支
内联不是越激进越好。有些方法逻辑虽短但调用频次低，强行塞进caller反而增大code cache压力，影响其他更热路径的编译机会。盯住LogCompilation里的code_size和inline_level，比盲目调参实在得多。
