一个看似简单却未被内联的热点方法
假设你负责一个微服务，核心接口的响应时间要求低于 50 毫秒。压测时发现，某个工具方法 StringUtils.normalize 被调用了数百万次，但通过 -XX:+PrintInlining 查看日志，却看到 hot method too big 的提示，方法没有被内联。你可能会疑惑：这个方法明明很小，为什么 JIT 编译器不把它内联？
这个问题的答案涉及 HotSpot C2 编译器内联决策的完整机制。方法内联是 JIT 编译中最重要的优化之一，它不仅能消除方法调用本身的开销，还能为后续优化（如逃逸分析、死代码消除）创造机会。但内联并非没有代价：内联会增加编译时间，生成更长的机器码，占用更多代码缓存。因此，C2 编译器需要一套复杂的决策规则，在收益与成本之间权衡。
本文以微服务中频繁调用的工具方法优化为贯穿场景，分析 C2 编译器如何根据方法大小、调用频率和调用深度决定内联，解释虚方法内联的去虚拟化技术，并演示如何通过 JVM 参数和诊断日志优化内联行为。
内联的收益与成本
方法内联的核心收益是消除调用开销。在 JVM 中，一次方法调用需要保存当前执行位置、创建被调用方法的栈帧、传递参数、执行方法体、恢复调用者状态。对于 getter/setter 这类简单方法，调用开销可能比方法体本身还大。内联后，这些操作简化为直接的字段访问。
更重要的收益是内联能触发后续优化。当方法体被复制到调用者中，编译器可以在更大的 IR 图上进行优化。例如，如果被内联的方法返回一个常量，编译器可以传播这个常量，消除后续的条件判断；如果内联后对象没有逃逸，逃逸分析可以将其分配在栈上，减少 GC 压力。
但内联也有成本。首先，内联会增加编译时间，因为编译器需要解析更多字节码，构建更大的 IR 图。其次，内联会生成更长的机器码，占用更多代码缓存（Code Cache）。代码缓存是有限的内存区域，如果被占满，JIT 编译器会被关闭，所有代码退回解释执行，性能会断崖式下跌。因此，编译器必须谨慎选择内联哪些方法。
C2 内联决策的输入：方法大小、热度与调用深度
C2 编译器在解析字节码的过程中决定是否内联每个方法调用。它主要考虑三个因素：方法体大小、方法调用频率（热度）和调用深度。
方法体大小是内联决策的首要因素。HotSpot 使用字节码长度来估计方法大小，有两个关键参数：-XX:MaxInlineSize 和 -XX:FreqInlineSize。MaxInlineSize 的默认值是 35 字节，适用于非热点方法；FreqInlineSize 的默认值是 325 字节（64 位 Linux 上），适用于热点方法。如果方法字节码大小超过这些阈值，即使调用频繁，也不会被内联。
调用频率通过方法调用计数器来度量。在分层编译中，方法在解释执行阶段会收集 profiling 数据，包括调用次数和循环回边次数。当调用次数达到一定阈值（如 Tier 3 的 2000 次），方法会被 C1 编译并继续收集数据；当达到 Tier 4 的阈值（如 15000 次），会被 C2 编译。但内联决策不仅看方法本身的热度，还看调用点（call site）的热度。C2 会根据 profiling 数据估计每个调用点的执行频率，频率高的调用点更有可能内联。
调用深度是指内联嵌套的层数。C2 不会无限内联，因为内联嵌套过深会导致 IR 图爆炸，编译时间急剧增加。HotSpot 有一个参数 -XX:MaxInlineLevel，默认值是 9，表示内联的最大嵌套深度。此外，还有 -XX:MaxRecursiveInlineLevel 控制递归内联的深度，默认值是 1，即通常不内联递归方法。
这些参数共同构成了内联决策的边界。一个方法即使很小，如果调用深度超过限制，也不会被内联。
内联决策的完整流程
C2 在解析字节码时，遇到方法调用指令（如 invokevirtual、invokestatic）会执行以下决策流程：
- 检查方法是否可内联。如果方法是 native 方法或抽象方法，通常无法内联。如果方法未被加载，也无法内联。
- 检查方法大小。如果方法字节码大小超过
MaxInlineSize（非热点）或FreqInlineSize（热点），则拒绝内联，并记录原因too big或hot method too big。 - 检查调用深度。如果当前内联深度已达到
MaxInlineLevel，则拒绝内联。 - 检查调用频率。如果调用点不热，但方法很小（小于
MaxTrivialSize，默认 6 字节），仍然可能内联；否则，需要调用频率达到阈值。 - 对于虚方法，执行去虚拟化分析（见下一节）。
- 如果所有检查通过，则内联目标方法，并递归处理目标方法内部的调用。
这个流程可以用以下 Mermaid 流程图表示：
flowchart TD
A[遇到方法调用字节码] --> B{方法可内联?}
B -- 否 --> R[不内联]
B -- 是 --> C{方法大小 <= MaxInlineSize 或 FreqInlineSize?}
C -- 否 --> R
C -- 是 --> D{调用深度 < MaxInlineLevel?}
D -- 否 --> R
D -- 是 --> E{调用点够热?}
E -- 否 --> F{方法大小 <= MaxTrivialSize?}
F -- 是 --> G[内联]
F -- 否 --> R
E -- 是 --> G
G --> H[递归处理被内联方法内部的调用]
在实际的 C2 实现中，决策顺序和条件可能更复杂，但上述流程反映了核心逻辑。
虚方法内联与去虚拟化
虚方法（public 非 final 方法）的调用在字节码层面是 invokevirtual，JVM 需要在运行时根据对象的实际类型分派到正确的方法实现。这种动态分派本身就有开销，而且编译器在编译时无法确定目标方法，因此通常无法内联。
然而，C2 编译器有一种技术叫做“去虚拟化”（devirtualization），可以在某些情况下将虚方法调用转换为直接调用，从而允许内联。去虚拟化依赖 profiling 数据中的类型信息。C2 在解释执行阶段会记录每个调用点的实际类型分布。如果某个调用点绝大多数情况下都指向同一个类型，C2 就会假设该类型，并插入一个类型检查（如 checkcast 或 type profile 检查），如果检查通过，则直接调用该类型的方法实现。
这种优化被称为“乐观去虚拟化”。它假设类型分布不会变化，如果运行时遇到不同的类型，会触发去优化（deoptimization），回退到解释执行，并重新收集 profiling 数据。
去虚拟化使得虚方法内联成为可能。例如，一个接口方法 Handler.handle() 在调用点只被 OrderHandler 实现，C2 可以内联 OrderHandler.handle() 的方法体，并插入类型检查。如果类型检查失败，则跳转到慢路径。
去虚拟化的收益是显著的，但前提是类型分布稳定。如果调用点存在多个实现类，且频率相近，C2 可能无法去虚拟化，导致内联失败。在这种情况下，可以考虑使用 final 关键字或重构代码，减少多态性。
诊断内联失败：-XX:+PrintInlining 实战
要了解哪些方法被内联、哪些没有，以及原因，可以使用 -XX:+PrintInlining 参数。这个参数需要配合 -XX:+UnlockDiagnosticVMOptions 使用。输出日志以树状结构显示方法调用关系，每个调用点会标注内联结果。
常见的标注包括：
inline (hot)：热点方法，已内联。too big：方法太大，未内联。hot method too big：热点方法，但太大，未内联。callee is too large：被调用方法太大。not inlineable：方法不可内联，如 native 方法或未加载的类。intrinsic：方法被替换为内部函数（intrinsic），相当于内联。
回到开头的场景，StringUtils.normalize 方法被标记为 hot method too big，说明它的字节码大小超过了 FreqInlineSize 的默认值 325 字节。虽然它被频繁调用，但 C2 认为内联的收益不足以抵消代码膨胀的成本。
优化方向有两个：一是减小方法体，二是调整 JVM 参数。减小方法体是更推荐的做法，因为内联算法更青睐小方法。可以将大方法拆分成多个小方法，每个方法只做一件事，这样每个小方法都可能被内联。例如，normalize 方法可能包含多个 if 分支和循环，可以提取出 trimToNull、removeControlChars 等子方法。
调整参数是最后的手段。-XX:FreqInlineSize 可以增大，但会增加编译时间和代码缓存压力。-XX:MaxInlineSize 影响非热点方法的内联，通常不建议修改。修改参数前，应通过监控数据确认内联确实是性能瓶颈，而不是盲目调优。
参数调优与权衡
调整内联参数需要在编译时间、代码缓存和运行时性能之间权衡。以下表格总结了常用参数及其影响：
| 参数 | 默认值 | 作用 | 调大后果 | 调小后果 |
|---|---|---|---|---|
-XX:MaxInlineSize | 35 | 非热点方法的最大内联字节码大小 | 更多方法被内联，编译时间增加，代码缓存占用增加 | 更少方法被内联，调用开销增加 |
-XX:FreqInlineSize | 325 | 热点方法的最大内联字节码大小 | 热点大方法可能被内联，但代码膨胀风险高 | 热点大方法不被内联，可能损失性能 |
-XX:MaxInlineLevel | 9 | 内联最大嵌套深度 | 更深的内联链，编译时间增加 | 浅层内联，可能错过跨层优化 |
-XX:MaxRecursiveInlineLevel | 1 | 递归内联的最大深度 | 允许递归内联，但可能导致无限内联 | 禁止递归内联，避免编译爆炸 |
这些参数的默认值在 JDK 17 中已经过优化，适合大多数场景。非特殊场景不建议修改。修改前应使用 -XX:+PrintInlining 和 -XX:+PrintCompilation 收集数据，确认内联失败是性能瓶颈。
除了调整参数，还可以使用 Compiler Control 指令（-XX:CompilerDirectivesFile）对特定方法强制内联或禁止内联。例如，可以编写一个 JSON 文件，指定某个方法必须内联，即使它很大。这比全局调整参数更精细，但需要谨慎使用，因为强制内联可能导致代码缓存溢出。
常见失败模式与诊断路径
内联优化在生产环境中可能遇到以下问题：
代码缓存耗尽。如果内联过多，生成的机器码占用大量代码缓存，可能导致 CodeCache is full 警告，JIT 被关闭。诊断方法：使用 jcmd VM.code_cache 查看代码缓存使用率，或通过 JMX 监控。
编译线程过载。内联决策和编译本身消耗 CPU，如果编译队列积压，可能导致方法长时间停留在解释执行，性能下降。诊断方法：使用 -XX:+PrintCompilation 查看编译时间，或使用 JFR 的 jdk.Compilation 事件。
去虚拟化失败。如果虚方法调用点的类型分布不稳定，去虚拟化可能失败，导致内联未发生。诊断方法：在 -XX:+PrintInlining 日志中查找 virtual call 或 not mono 等标注。
参数调整不当。盲目增大 FreqInlineSize 可能导致代码膨胀，反而降低性能。诊断方法：对比调整前后的 -XX:+PrintCompilation 日志和性能指标。
优化内联的正确路径是：先通过 -XX:+PrintInlining 定位内联失败的方法，再分析原因（大小、深度、虚方法），优先通过代码重构减小方法体，最后才考虑调整参数或使用 Compiler Control。
总结与适用边界
方法内联是 JIT 编译器最重要的优化之一，它通过消除调用开销和触发后续优化来提升运行时性能。C2 编译器根据方法大小、调用频率和调用深度做出内联决策，虚方法内联依赖去虚拟化技术。-XX:+PrintInlining 是诊断内联行为的核心工具，可以帮助开发者理解为什么某些方法未被内联。
调整内联参数是一种权衡：增大内联阈值可能提升性能，但会增加编译时间和代码缓存压力。在大多数情况下，默认参数已经足够好，优化应优先从代码结构入手，而不是修改 JVM 参数。
本文的讨论基于 HotSpot 的 C2 编译器，其他 JVM（如 GraalVM）的内联决策可能不同。此外，内联行为属于实现细节，不同 JDK 版本的默认参数可能变化，生产环境调优应以实际监控数据为准。