原文来自于：https://zha-ge.cn/java/96

颠覆认知！synchronized 的轻量级锁竟然还会自旋？

前些天，项目组里刮起一阵“性能优化”旋风。大家嘴里念叨得最多的，就是 synchronized。你以为 synchronized 还停留在“重量级锁开销大、能不用别用”的时代？哎，too young, too simple。有同事突然冒出一句：“你知道轻量级锁会自旋么？” 我心里那个一惊，啥玩意？自旋我知道，但不是只有自旋锁（spin lock）和偏向锁那一套撩妹操作么？轻量级锁还能自旋？我的认知小船翻了。

说起来，本来我一直用了十几年的 synchronized，早就当它透明胶带：粘一粘，线程安全就稳了。直到看热心网友贴出来的 JVM 官方文档，才发现原来 synchronized 内部也有个熬夜加班的“小老弟”——自旋。

synchronized 锁升级流程：

• 偏向锁
• 轻量级锁（可能自旋）
• 重量级锁（OS 层阻塞）

你没看错，真·自旋，出现在了轻量级锁阶段！

探索过程：锁的“瘦身房”与自旋岗

那天熬夜调代码，忍不住扒拉出 jvisualvm 跟踪锁的情况。说实话，一开始我还以为自旋只跟 ReentrantLock 那种高阶锁精英挂钩，synchronized 这种老实人不会玩这一套。谁知道 JVM 1.6 以后，synchronized 静悄悄地玩起了锁升级+自旋优化！

简单来说，轻量级锁抢不到怎么办？慌什么！线程先自旋个几次——有机会就抢过来，没机会再罢休。换句话说，JVM 在“阻塞”之前还会帮你“抢红包”兜底几下，说不定你卡个 1ms 就能等到 CPU 空。

我随手写了个脑筋急转弯式的多线程代码测试（[完整示例略]），线程争锁的时候明显能感觉比老版 JVM 更“丝滑”。

只看关键代码逻辑：

synchronized (lock) {
    // 临界区代码
    doSthImportant();
}
// JVM 内部：如果锁已轻量级化，CAS 尝试获取锁
// 若失败，线程本地自旋次数，等锁释放再抢

你看，JVM 真不是简单粗暴地让你傻等。

踩坑瞬间

当然，自旋背后也有坑货时刻。举个例子：

• 多线程并发极高时，轻量级锁依然会撑不住，很快升级成“重量级锁”，从会场 VIP 区秒变大排长队，性能立马暴跌。
• 自旋也是“徒劳等待”——万一锁持有者忙着GC或I/O，兄弟你再怎么转也只是在原地打转，CPU 就这么白白烧光。

我有次手贱把 synchronized 放到了很大的代码块上，结果 CPU 飙升，线程堆积，“自旋”变成了“原地画圆”（线程：我到底在等什么？）。真是又气又好笑。

经验启示

码代码久了，归纳如下几点生存小妙招：

• synchronized 其实很聪明，JVM 已帮你做了不少“骚操作”，不用过分妖魔化它。
• 遇到频繁竞争，锁粒度要细，临界区能短则短，别让自旋线程干等太久。
• 想极致性能且偏好 DIY，可以考虑显式用 java.util.concurrent 包里的锁，但别轻视 synchronized 的进化史。
• 工具很重要，有事多用 jstack、jvisualvm 等实时监控，别拍脑袋猜测锁状态。

最后，synchronized’s not dead。别小瞧了轻量级锁下那颗自旋的心。从此，每次写 synchronized，总感觉背后有个 JVM 小哥在我耳边说：“兄dei，放心，让我帮你兜一把！”

好啦，今天先聊到这，码字都快饿了。谁能想到 synchronized 背后藏了那么多脑洞呢？下回也许还得扒拉扒拉偏向锁的故事……下期再见👋。