需同时启用-XX:+PrintCompilation和-XX:+PrintInlining才能确认方法是否被内联，前者显示编译行为，后者输出内联决策详情，成功内联标记为“inline (hot)”，失败常见原因包括方法过大、含synchronized或异常块、虚方法未确定实现等。
怎么打开 JIT 编译日志并确认方法是否被内联
直接加 -XX:+PrintCompilation 启动 JVM，就能看到哪些方法被编译、何时编译、用了哪个编译器（C1/C2）。但光看这个不够——它不告诉你内联决策。必须配合 -XX:+PrintInlining，JVM 才会在编译时打印每处调用是否内联、为什么失败。
常见失败原因包括：
- 目标方法字节码超过
35（默认阈值），可用-XX:MaxInlineSize=45临时放宽 - 方法是虚方法（未声明
final/private/static），且运行时无法确定唯一实现 - 调用链太深，触发了
-XX:MaxInlineLevel限制（默认 9 层） - 方法体含
synchronized或异常处理块，JIT 默认规避内联
如何从日志里识别真实的内联行为而非“假阳性”
-XX:+PrintInlining 输出里带 inline (hot) 表示成功内联；too big、not hot、too many arguments 是典型拒绝理由。但要注意：日志只反映编译时刻的快照，而 JIT 会动态重编译。比如某方法刚被 C1 编译时未内联，后续被 C2 深度优化时可能补上内联——这时你会在日志里看到两条记录，后一条才代表最终策略。
关键点：
- 关注
hot标记，不是所有被编译的方法都会被内联 - 同一方法名可能多次出现，按时间戳排序，取最后一条为准
- 如果看到
already compiled into nmethod却没 inline 提示，说明该次编译未触发内联流程
为什么 String.length() 几乎总被内联，而 list.get(i) 很难
前者是 final 方法，字节码仅一条 iload + ireturn，体积远低于 35 字节码阈值；后者是接口方法，实际调用目标在运行时才确定（如 ArrayList 或 LinkedList），属于虚方法调用。JIT 默认不内联虚方法，除非开启 -XX:+UnlockDiagnosticVMOptions -XX:+UseTypeProfile 并积累足够类型信息。
实操建议：
- 高频访问字段或简单计算，优先封装为
private static小方法 - 避免在热点循环里调用接口方法，可提前将
List转为具体类型引用 - 用
-XX:+LogCompilation生成 XML 日志，再用 JITWatch 可视化查看内联树结构
内联边界变化的实际影响：代码膨胀与缓存失效
强行提高 -XX:MaxInlineSize 或 -XX:FreqInlineSize 确实能让更多方法被内联，但代价明显：生成的机器码体积增大，指令缓存（i-cache）命中率下降，尤其在多核并发场景下，可能反而拖慢整体吞吐。这不是理论风险——实测中把阈值从 35 改到 100，某些数值密集型服务的 L1-i 缓存未命中率上升 12%，端到端延迟波动加大。
真正需要盯住的是：
-
-XX:ReservedCodeCacheSize是否告警（CodeCache is full） - JITWatch 中 “Inline Tree” 深度是否超过 5 层，过深说明内联失控
- 对比开启/关闭
-XX:+PrintInlining时的 GC 日志，观察元空间（Metaspace）增长速率
内联不是越狠越好，而是让 JIT 在“消除调用开销”和“保持代码密度”之间做实时权衡——你看到的日志，只是它某一秒的决策快照。
