要看到有效内联日志，必须配齐三件套：-XX:+UnlockDiagnosticVMOptions、-XX:+PrintInlining 和 -XX:+PrintCompilation；仅加后两者常无输出，因 PrintInlining 依赖 JIT 达到 Tier 2/4 编译层级，而 PrintCompilation 可触发热点方法提前编译，使内联决策实际发生并记录。
直接加参数不一定能看到内联日志，得配齐三件套
单独加 -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining 很可能没输出，因为 PrintInlining 依赖 JIT 编译器进入足够高的编译层级（Tier 2 或 Tier 4），而默认启动时多数方法还在解释执行或 C1 编译阶段。必须搭配 -XX:+PrintCompilation，它能触发 JIT 提前编译热点方法，让内联决策实际发生并被记录。
-
-XX:+UnlockDiagnosticVMOptions是开关，不加它PrintInlining直接被忽略 -
-XX:+PrintCompilation让你看到哪些方法被编译、用的是 C1 还是 C2 -
-XX:+PrintInlining只在方法被编译且 JIT 尝试内联时才打印决策细节，比如inline (hot)或callee is too large
grep 筛选关键信息时别漏掉编译层级和失败原因
日志里真正有用的不是“已内联”，而是“为什么没内联”。C1 和 C2 的拒绝理由不同，得分开看：
- C1 日志常见提示：
callee is too large→ 方法字节码超过-XX:MaxInlineSize（默认 35 字节） - C2 日志常见提示：
hot method too big→ 调用太热但方法体太大，超过-XX:FreqInlineSize（默认 325 字节） - 还有
already compiled into a big method→ 被内联的目标方法本身已被编译成大块代码，再塞进去会超-XX:InlineSmallCode限制（默认 2000 字节） - 搜索时建议用：
java MyApp | grep -E "(inline|too big|hot method|big method)"
内联深度不是越深越好，JIT 有隐式层数限制
JIT 不会无限制展开调用链，尤其当链中出现同步块、异常处理、虚方法调用或未加载类时，内联会在某一层戛然而止。典型表现是：A → B → C 被内联，但 C → D 没出现日志，且 D 的编译日志里没有 inline 字样 —— 这往往说明 D 因含 synchronized 或 try-catch 被跳过。
- 没有显式参数控制“最大深度”，但实际中 C2 通常只允许 9 层以内（含递归计数）
- 如果 A 调用 B，B 调用 C，C 调用 D，而 D 是
ArrayList.get()，它大概率会被内联；但如果 D 是自定义的带finally块的方法，基本不会进内联队列 - 用
-XX:+LogCompilation生成 XML 日志，再用 JITWatch 查看“inlining tree”视图，比纯文本更直观看出断点在哪一层
别把日志当性能证据，得结合真实延迟/吞吐验证
看到 inline (hot) 不代表性能一定变好，有时内联后反而因代码膨胀导致指令缓存（i-cache）压力上升，或寄存器分配紧张拖慢执行。反过来，没内联也不等于慢 —— JIT 可能用逃逸分析消除了对象分配，或用分支预测优化了条件逻辑。
- 观察点优先级：先看
PrintCompilation输出里方法是否从1（C1）升到4（C2 optimized），再看PrintInlining是否随之变化 - 改完代码后，用 JMH 测量
AverageTime和SampleTime分布，避免只盯日志里的“成功”字样 - 特别注意：如果方法刚启动就高频调用（如 static 初始化块里的逻辑），JIT 可能来不及编译，
PrintInlining完全静默 —— 此时要加-XX:CompileCommand=dontinline,*ClassName.methodName强制不内联作对照
内联日志只是 JIT 决策的快照，不是性能判决书。最常被忽略的是：日志里没出现的方法，未必没被优化；而反复出现“inline (hot)”的方法，也可能因后续代码膨胀被降级回解释执行。
