Java源码执行快慢关键在于JVM能否对高频小方法实施方法内联，即JIT在运行时将其字节码展开至调用点以消除压栈、跳转等调用开销，并支持去虚化与后续优化，但受方法大小、热度、结构等条件限制。
Java 源码执行快不快，关键不在写法多炫，而在 JVM 能不能把频繁调用的小方法“塞进”调用处直接跑——这就是方法内联，也是 JIT 优化里最常见、最见效的一环。
方法内联：不是复制粘贴，而是智能折叠
方法调用本身有开销：压栈、传参、跳转、清栈。哪怕一个 return a + b，每次调用都要走一遍流程。JIT 在运行时发现某个方法被高频调用（比如循环里反复调用的 square()），且方法体足够短（通常字节码不超过 325 字节，默认阈值），就会把它“展开”到调用点，相当于把函数体原地插入，消除调用指令。
这不是简单文本替换，而是在字节码分析阶段完成的语义等价转换。JIT 还会结合类型信息做去虚化（devirtualization）：如果能确定多态调用的实际目标（比如子类唯一、final 方法、私有方法），就绕过动态分派，让内联更稳。
- 内联成功后，后续执行不再进入该方法栈帧，CPU 流水线更连续
- 内联还为后续优化铺路，比如常量传播——一旦
square(5)被内联，JIT 可能直接算出25并替换掉整个表达式 - 但不会无脑内联：递归方法、过大方法、含异常处理块的方法，或调用链过深时，JIT 会主动放弃，避免代码膨胀拖慢缓存命中率
JIT 编译器怎么知道该内联谁？靠两个计数器
JVM 不靠猜，靠实测。HotSpot 用两套独立计数机制识别“值得优化”的代码：
立即学习“Java免费学习笔记（深入）”；
-
方法调用计数器：统计方法被调用次数。默认 Server 模式下达到 10000 次触发 C2 编译（含内联）；Client 模式是 1500 次。这个阈值可通过
-XX:CompileThreshold调整 - 回边计数器：专盯循环——每次循环跳回头部（back edge）就加一。一个长循环哪怕只被调用一次，只要内部迭代百万次，也能被识别为热点，触发栈上替换（OSR），连正在跑的循环体都直接编译+内联
这两个计数器还带衰减机制（-XX:+UseCounterDecay 默认开启），冷方法的计数随时间下降，防止长期占用编译资源。
分层编译让内联更聪明：从快到稳，逐级加码
现代 JVM（Java 7+ 默认启用）不是只用一种编译器，而是五层协作：
- 第 0 层：纯解释执行，同时收集调用和回边数据
- 第 1–3 层：C1 编译器介入，做轻量内联、空检查消除等，启动快、延迟低
- 第 4 层：C2 编译器接手，基于前几层积累的 profiling 数据，做深度内联（包括跨调用链的多层内联）、循环展开、冗余计算消除等激进优化
也就是说，同一个方法可能先被 C1 快速内联一次，等它真正“热起来”，再被 C2 重新编译，内联更深、更准——比如把 A→B→C 三级调用全摊平成一行计算逻辑。
看得到的验证方式：用 JVM 参数打开内联日志
想确认某段代码是否被内联，可以加参数运行：
-XX:+PrintInlining -XX:+UnlockDiagnosticVMOptions
输出类似：
inline (hot) java.lang.Math.min(int,int) hot method too biginline (hot) com.example.Utils.square(I) inline worked
绿色表示尝试失败（方法体超限），蓝色表示成功。配合 -XX:+PrintCompilation 还能看到哪个方法在第几层被编译、耗时多少。
