java中synchronized锁升级机制不支持运行时自动锁降级，设计为单向不可逆：无锁→偏向锁→轻量级锁→重量级锁；一旦升级为重量级锁便永久保持，仅在g1回收或安全点等全局干预下批量撤销偏向锁，而非单个锁回退。
Java 中 synchronized 的锁升级机制不支持运行时自动锁降级，这是 HotSpot JVM 的明确设计选择。
锁升级是单向不可逆的
从无锁 → 偏向锁 → 轻量级锁 → 重量级锁的路径严格单向。一旦锁升级为重量级锁，对象头 Mark Word 中的锁标志位变为 10，指向 Monitor 对象，JVM 不会再将其还原为轻量级锁或偏向锁。
- 重量级锁状态由操作系统互斥量维护，线程阻塞/唤醒逻辑与轻量级锁的 CAS 自旋完全不同，降级需重建锁记录、恢复栈帧结构，开销大且易出错
- JVM 认为：高竞争后突然回归无竞争的概率低，频繁升降级反而损害性能
- 即使所有线程都已释放锁，该对象仍保持重量级锁状态，后续首次加锁直接走 Monitor 流程
所谓“降级”仅发生在特殊系统干预场景
这不是锁状态的主动回退，而是全局性撤销或重置，不改变单个锁的生命周期：
- G1 垃圾回收的并发标记阶段：会批量撤销所有偏向锁（设为无锁状态），但这不是“从重量级降为偏向锁”，而是强制清空偏向信息
- JVM 安全点（SafePoint）触发的批量撤销：当检测到某类对象频繁发生偏向锁撤销时，可能禁用后续该类对象的偏向锁，但已有重量级锁不受影响
- 手动关闭偏向锁：
-XX:-UseBiasedLocking启动参数可禁用偏向锁，新对象跳过偏向阶段，但已升级的锁不会回退
开发者能做的“等效降级”策略
无法让已升级的锁自动变轻，但可通过代码设计避免锁长期处于重量级：
- 缩小同步块范围：只包裹真正共享操作，减少竞争窗口
- 用更细粒度锁替代大对象锁：比如将一个集合锁拆为多个桶锁
- 读多写少场景改用
ReentrantReadWriteLock或StampedLock，读操作不阻塞 - 无锁化改造：高频计数用
AtomicInteger，状态更新用AtomicReference+ CAS
锁升级本身是 JVM 的自适应优化，而锁降级未被纳入机制——它不是遗漏，而是权衡后的取舍。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
