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

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

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

偶遇 synchronized的小心思

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

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

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

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

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

懂点原理，别和 JVM 抬杠

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

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

你可以这么想：

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

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

关键代码来了

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

java 复制代码

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 进阶，我再"补一嘴"！