synchronized锁升级对代码零侵入，jvm自动完成无锁→偏向锁→轻量级锁→重量级锁的切换，无需修改语法或配置；不引入新api、异常处理或手动释放逻辑，避免死锁与模板代码；但可能掩盖同步粒度不合理的设计问题。
synchronized 锁升级本身不增加代码复杂度，它完全由 JVM 在底层自动完成，开发者无需修改任何语法、也不用显式配置或干预升级过程。
对编码方式零侵入
你写 synchronized(this) { ... } 或 public synchronized void method() {}，和十年前一模一样。JVM 会根据运行时线程竞争情况，默默在对象头（Mark Word）里切换锁状态——从无锁 → 偏向锁 → 轻量级锁 → 重量级锁。整个过程对源码透明，编译期、字节码层、运行期都不需要你写额外逻辑。
不引入新概念或错误分支
不同于 Lock 接口需手动 lock()/unlock()、处理异常、加 finally 块，synchronized 的加锁/释放始终绑定在作用域边界上。没有 tryLock() 返回布尔值要判断，没有中断响应要捕获 InterruptedException，也没有公平性开关要传参。这意味着：
• 不会因忘记 unlock 导致死锁
• 不会出现 try-finally 模板代码污染业务逻辑
• 不需要为锁状态设计兜底策略或降级路径
调试与理解成本未上升
虽然锁升级机制本身较复杂，但日常开发中几乎不需要感知它。只有在高并发压测时观察到 CPU 升高、自旋增多或线程阻塞突增，才可能需要借助 jstack、JFR 或 -XX:+PrintSynchronizationStatistics 等工具分析锁状态。而这种分析属于性能调优范畴，并非编码阶段的负担。普通业务代码仍保持“加个关键字就安全”的极简风格。
潜在间接影响：过度依赖可能掩盖设计问题
锁升级让 synchronized 在低竞争下“看起来很轻”，容易让人忽略同步粒度是否合理。例如：
• 把整个方法用 synchronized 修饰，却只有一行共享变量操作
• 在循环体内反复进入同一把锁，本可用局部变量或 CAS 替代
这类写法虽不增加语法复杂度，但会拖慢实际吞吐，后期排查时才发现是锁升级失效（快速升为重量级锁）所致。本质上不是锁升级提高了复杂度，而是它降低了对并发设计的警觉性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
