方法内联是JVM JIT编译器将小而热的方法体直接复制到调用处以消除调用开销并启用深度优化的运行时技术；其触发依赖热点频率、字节码大小、无副作用等条件，而非人工展开逻辑。
小方法在 JVM 中不等于低效，反而更容易被内联，从而获得比“手写大块逻辑”更高的执行效率。关键不是方法大小本身，而是它是否满足 JVM 内联启发式算法的判断条件。
为什么 add(int, int) 比直接写 a + b 在热点路径中更可能被优化
JVM 的 C2 编译器对方法是否内联，不看“你写了什么”，而看“它怎么被用”。一个简单、无副作用、被高频调用的小方法（如 add、isEmpty()、size()），天然符合内联触发条件：
- 方法体字节码少（默认阈值：C1 编译器 ≤ 35 字节，C2 默认 ≤ 325 字节）
- 调用点被 JIT 观测到足够“热”（例如循环内被调用上万次）
- 没有虚方法调用、未被动态代理、非 synchronized（或已锁消除）
- 不是构造器、native 方法或已被标记为
@HotSpotIntrinsicCandidate的特殊方法（这类走 intrinsic，不走普通内联流程）
反过来看，如果你把 a + b 直接展开在调用处，JVM 就失去了识别“这是一个可复用、可预测、可优化单元”的上下文 —— 它无法跨多处统一替换、也无法基于该方法做常量传播或冗余检查消除。
-XX:+PrintInlining 能告诉你哪些方法真正被内联了
加这个 JVM 参数后，控制台会输出每一处内联决策，包括成功/失败原因。常见失败提示有：
-
too big：方法体超字节码限制 -
hot method too big：虽然单个方法不大，但调用链总深度超默认9 -
not hot enough：调用频次未达阈值（通常需 > 10k 次） -
virtual call too complex：多态分派目标不唯一，JVM 不敢贸然内联
注意：输出中的 inline (hot) 表示成功；did not inline 后跟原因才是重点。不要只盯着“成功”，更要分析“为什么没成功”。
内联不是越深越好，-XX:MaxInlineLevel 和 -XX:MaxRecursiveInlineLevel 控制实际深度
C2 默认最多内联 9 层（-XX:MaxInlineLevel=9），递归调用单独限制为 1 层（-XX:MaxRecursiveInlineLevel=1）。这意味着：
- 哪怕所有方法都极小，
a() → b() → c() → ... → j()第 10 层的k()也不会被内联 - 递归方法如
fib(n)即使 n=1 时只有一行，也大概率不会被内联（除非手动展开为迭代） - 修改这些参数可能让某些路径变快，但也可能因 code bloat 导致指令缓存失效，实测前务必压测
真实瓶颈往往不在“能不能内联”，而在“内联后能否触发后续优化”——比如内联后 JIT 才发现 if (x == null) 永远为 false，进而删掉整段分支。
真正影响性能的，从来不是“写了一个小方法”，而是“这个小方法是否处于热点路径 + 是否具备稳定调用形态 + 是否被 JIT 持续观测到”。别为了“避免方法调用”而强行扁平化代码；让 JVM 自己决定哪里该内联，比人肉猜更可靠。
