synchronized 代码块虽不直接阻止 jit 内联，但因破坏控制流线性、增加 cfg 复杂度、干扰逃逸分析及与异常处理共存，显著降低内联成功率；应将纯计算逻辑抽离为无锁的 private/static/final 方法以提升内联概率。
synchronized 代码块本身不直接阻止 JIT 内联，但会显著降低内联成功率——关键在于它破坏了 JIT 对控制流线性、方法纯度和调用稳定性的判断。
monitorenter/monitorexit 指令干扰控制流分析
JIT 在决定是否内联一个方法时，需要清晰建模其入口、出口和所有可能的跳转路径。synchronized 块引入的 monitorenter 和 monitorexit（包括编译器自动插入的异常出口处的 monitorexit）会让方法控制流变得“非线性”：
- 每个 return、break、continue 或 throw 都可能触发 monitorexit，JIT 必须为每条出口路径复制锁释放逻辑
- 这种多出口结构增加 CFG（Control Flow Graph）复杂度，导致 JIT 放弃内联，尤其在 C1 编译阶段
- 即使方法体只有几行，只要包含 synchronized 块，JIT 日志中常出现 "not inline (hot) because: has monitor" 提示
锁对象逃逸与内联保守性增强
如果 synchronized 锁对象（如 new Object() 或局部变量）被证明不会逃逸出当前方法，JIT 可能做锁消除；但这一分析本身就会抑制内联：
- 逃逸分析需额外计算开销，JIT 会优先保障分析正确性而非激进优化
- 一旦锁对象存在逃逸风险（例如传入外部方法、存入集合、作为返回值），JIT 立即标记该方法为“含同步”，默认跳过内联
- 对比：一个无锁、无 try-finally 的 private static 方法，哪怕稍大一点也容易内联；而同体积带 synchronized 的方法，几乎必然被拒
实际影响比语法位置更关键
很多人关注“synchronized 写在循环内还是外”，但这不是主因。真正起决定作用的是：
-
锁粒度是否覆盖热路径核心逻辑：若整个计算密集型循环体被 synchronized 包裹，JIT 很难将循环内方法（如
process(i)）内联，因为调用点位于同步上下文中 - 是否与异常处理共存：synchronized + try-catch 组合是内联“双杀”——monitorenter 和异常表共同污染控制流，JIT 几乎必定绕过
-
锁对象是否静态或全局：使用
static final Object LOCK = new Object()虽利于锁粗化，但因锁生命周期长、竞争面广，JIT 更倾向将其视为“不稳定热点”，降低内联意愿
提升内联概率的可行做法
目标不是去掉同步，而是让 JIT “看不见”它对热路径的影响：
- 把纯计算逻辑抽成独立的 private / static / final 方法，确保不含 synchronized、try、finally、lambda 或非 final 字段访问
- 同步只保留在最外层调度方法中（如 service 层），子方法保持“裸函数”形态，便于 JIT 大胆内联
- 避免在泛型工具方法、Stream 中间操作（如 filter/map）里嵌套 synchronized——这类方法本就因泛型擦除+桥接方法+潜在异常而内联困难，再加锁基本等于关闭优化通道
- 用 -XX:+PrintInlining 验证：关注日志中是否出现 "inline (hot)"，以及失败原因是否为 "has monitor" 或 "virtual call"
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
