锁升级到底能不能“退烧”？synchronized 释放后状态解析

原文来自于：zha-ge.cn/java/97

锁升级到底能不能“退烧”？synchronized 释放后状态解析

啊哈，这个问题我最近还真有点感触。要不是上周项目组新同事提起“锁升级能不能降级（俗称‘退烧’）”，我还真没想到自己前几年的认知其实用词有多迷糊。说出来你别笑，Java 的 synchronized 锁升级过程，那真是比宿舍热水器的档位还复杂点。

偶遇 synchronized的小心思

这个故事要从一次“偶然”的 synchronized 性能调优说起。新需求来了，大家都在给某个高并发的缓存做加锁保护。理想画面里，synchronized、ReentrantLock 这些锁随用随走，锁状态自己聪明得很，锁住时候用升级，没人抢争马上退烧，“降级”，多么体贴——但事实真这样吗？

你把 synchronized 修饰的代码敲下去，JVM 内部其实要历经：

• 无锁
• 偏向锁
• 轻量级锁
• 重量级锁（就是 OS 层的粗大锁啦）

刚上手的小伙伴经常问：锁释放之后，它会不会再变回原来的更低档位？也就是重锁解掉后，会自动“退烧”到轻量级甚至无锁吗？

我的第一反应是：有道理，能省资源为啥不省？但真相就像“前任还会回来吗”这个鸡汤问题，理想很丰满，现实骨架瘦。

懂点原理，别和 JVM 抬杠

JVM 的 synchronized 锁升级是单向的： 偏向 → 轻量级 → 重量级 只要晋升过一次，哪怕后面没人抢，大哥级别的“重量级锁”标签就一直贴在对象头上了。

简单说，锁的升级是单行道，没有回头。

你可以这么想：

• 偏向锁就像一个偷偷摸摸的小偷，只有主人自己拿，不闹事。
• 轻量级锁像邻里借钥匙，大家排队还配合。
• 重量级锁，哎呀，一旦街坊们起冲突得叫警察，大家都得耐心排大队。

叫了警察，你觉得警察走了邻里还能回到单纯的小打小闹么？并/不/可！

关键代码来了

其实你用 synchronized 写点抢资源的小例子，JVM 的对象头里 mark word 会这样变化：

synchronized(obj) {
    // 偏向锁：仅有一个线程进来时
    // 轻量级锁：多线程交替但不抢
    // 重量级锁：有线程直接堵门等待
}
// 离开 synchronized 后，mark word 还会保留升级后的锁标记

踩坑瞬间

现实中，你肯定也试过：

• 我用 synchronized 配合几百个线程压力测，想验证下锁会不会自行降级。
• 线程走完 synchronized 段后，obj 还能否回到轻松状态？
• 我甚至 debug mark word 的内容，发现——锁升级后，结束 synchronized，那个“重量级锁”的痕迹一直搁那儿。

每一步我的内心都是：

• “不会吧，JVM 真懒得省资源？”
• “对象头不会‘自我修复’下吗？”
• “锁降级要是不支持，太浪费了……”

直到翻了 JVM 源码（狗头），结局彻底认清了：兄弟，认命吧，没降级这回事！

经验启示

来个非主流结尾鸡汤，总结几句：

• synchronized 的锁升级只有升级没有降级，“退烧”下线。
• 尽量避免在高并发下靠 synchronized 抢重锁，能用更轻快的锁（比如 CAS、LongAdder）就优先用。
• 重锁后的对象，哪怕一阵子没人用，也仍然背着“警察到过”的包袱。
• 真想“复健”，用锁分片、对象池化、线程局部变量等办法去规避。

最后友情推荐：

• 不要乱造锁升级降级的“性能幻想”，JVM 还是那个JVM。
• 多关注 Java Object Layout 工具，mark word 内容和锁状态一清二楚，避免拍大腿瞎猜。

唉，感觉自己像咖啡加班后胡思乱想，边啃代码边写下这些。 锁的故事说到这，下回遇到有关 Java 内存模型、底层 sync 进阶，我再“补一嘴”！