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

Java 自适应自旋锁机制详解：原理、优缺点与应用场景

说起 Java 的锁，大家是不是脑海里就浮现出 synchronized、ReentrantLock 那点“祖传招数”？嘿，其实 JVM 对锁可是“见招拆招”，招数多得你都分不清谁是亲儿子谁是干儿子。今儿咱来聊聊自适应自旋锁——这个听起来有点科幻、实则相当有用的小家伙。

起因：谁偷了我的效率？

前两天，项目里突发了一次 CPU 飙高“小地震”，同事们疯狂查 GC，我却本能地往线程堆栈一看，果不其然，锁竞争一片狼藉。啥情况？原来就是 synchronized 坏了好事。

你肯定吐槽：“锁抢不到不就等着吗，这不是古早戏码？”别急，JVM 可不是傻子。你等着就是浪费，何不让线程先自个儿“转两圈”，说不定锁很快就到手了。于是——自旋锁 上线！

自旋锁和自适应自旋锁：区别在于“会不会看脸色”

自旋锁，说白了，就是被阻塞的线程先不睡，CPU 上原地打转（忙等），“等你放锁我立刻扑过来，绝不错过旗舰抢购”。但死转也不是事儿，真让线程一直 spin 就太浪费了。

JVM 后来又玩出了花样：Adaptive Spin Lock——自适应自旋锁。

自适应的意思？
线程每次自旋尝试不会一味硬扛，会根据历史情况动态调整自旋时长。

• 上次这把锁自旋几下拿到了？多转转。
• 上次自旋到头还没拿到？别浪费时间，直接阻塞吧。

简直像极了生活里的“碰瓷专家”：一次说不定能成，但多半自知趣，见机行事。

关键代码一览

JVM 层的 spin lock 细节一般碰不到，但 synchronized 在 HotSpot 里的加锁流程大致可被抽象如下：

// 进入 synchronized 块时尝试自旋
for (int spins = 0; spins < maxSpins; spins++) {
    if (尝试获取锁()) {
        break; // 成功拿到，走你！
    }
    // 自旋一小会儿，再试
}
// 如果还是失败，那就乖乖 park 当前线程

自适应的奥义就在于 maxSpins 不是死板的，比如 HotSpot 里会这样调整：

• 上次线程自旋后直接成功了？ maxSpins++
• 上次自旋没成功反而进了阻塞？maxSpins–

而且有个“保底”：线程在 SMP（多核）机器上，自旋才有意义（单核干转没有用）。

踩坑瞬间

你以为自适应自旋锁就是“打怪利器”，实战里没踩坑？太天真！

• 高并发下锁竞争激烈： 线程全在自旋，CPU 全部被榨干，和没抢到锁没啥两样，服务器直接升天。
• 单核环境纯属瞎忙活： 线程怎么转都抢不到，还不是轮到就得切换。
• 大锁、小任务死循环： 有时候锁保护的代码块本身很重，自旋等半年还抢不到，全员浪费时间。
• 调优没头绪： JVM 参数啥都不调，默认自旋策略可能压根不适合你的场景。

经验启示

踩坑多了，总结就成了信仰，甩给你几个“看家口诀”：

• 用在合适场景：
  • 低延迟、锁持有时间极短的地方，自旋大概率能赢。
  • 锁刚好保护的就是一丢丢 critical section，配多核服务器，用它杠杠的。
• 别盲信自动：
  • 类似 -XX:UseSpinWait、-XX:PreBlockSpin 这种 JVM 参数不是装饰，合理搭配有奇效。
• 观察为本：
  • 用 jstack，top 盯着，锁竞争激烈就要警惕自旋锁引起的“假死”。
• 世界上没有银弹：
  • 并发魔法永远只适合对的那一刻，别贪手快，调查和验证才王道。

最后一句，多核的世界“机会只留给聪明的线程”，盲目自旋就容易被奴役。写锁相关代码，多点警觉，少点幻想，才是老铁的正确姿势。

收个尾，去杯咖啡，继续 debug——愿你永远不会被锁困住！

相关唠嗑或问题欢迎留言啊，大家一起踩坑一起飞！