原来自旋锁还能这么理解

原创于 2025-12-08 18:55:41 发布 · 558 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#java #开发语言 #自旋锁

个人观点，仅供参考！

先直接说结论：

自旋锁 = 脑子简单、死磕原地等；

适应性自旋锁 = 会“看情况”的自旋锁，更聪明，更贴近现代 JVM 的实现。

一、先搞懂：为什么需要自旋锁？

在讲自旋锁之前，先明确一个基础问题：普通阻塞锁的痛点。

假设你去奶茶店买奶茶（线程要执行临界区代码），收银台是「锁」，一次只能一个人用。

1、普通阻塞锁的思路

如果收银台有人（线程占用锁），你直接去休息区坐着等（线程阻塞），等店员喊你（线程唤醒）。但从排队区到休息区再回来，要走几步路（操作系统的「线程上下文切换」）—— 这几步路就是「开销」，而且成本很高。

2、自旋锁的思路

如果收银台的人很快就付完钱（锁持有时间极短），你何必去休息区？直接站在收银台旁边盯着（线程自旋），他一走你马上就能上前（拿到锁），省了来回走的开销。

二、自旋锁：“死等” 的实在办法

线程抢不到锁时，不马上跑去休息区（阻塞），而是在原地循环转圈（自旋），反复尝试抢锁，直到抢到为止，或者等够一定次数还没抢到，再去休息区。JDK1.6 之前的自旋锁是 “固定次数” 的（默认等 10 次）

1、举例（便于理解）

你买奶茶时，不管前面的人付款快不快，你都铁了心 “固定等 10 秒”。要是 10 秒内他付完了，你直接买（自旋成功）；要是 10 秒还没好，你再去休息区（自旋失败，转为阻塞）。

import java.util.concurrent.atomic.AtomicBoolean;

public class SimpleSpinLock {
    //AtomicBoolean原子布尔类，它保证了compareAndSet操作的原子性。
    //locked：表示锁的状态。false表示锁未被占用，true表示锁已被占用。
    private final AtomicBoolean locked = new AtomicBoolean(false);
    
    public void lock() {
        // 自旋等待，直到成功获取锁
        //compareAndSet(false, true)：CAS（Compare-And-Swap）操作
        while (!locked.compareAndSet(false, true)) {
            // 空循环
        }
    }
    
    public void unlock() {
        // 释放锁
        locked.set(false);
    }
}

2、自旋锁的优点和缺点

优点：

①避免上下文切换的高开销（自旋是用户态循环，不用麻烦操作系统）。

②锁持有时间极短时，效率超高。

缺点：

①自旋时会占用 CPU（线程空转，啥也不干就耗着 CPU 资源）。

②要是锁持有时间长、等待线程多，多个线程一起自旋会让 CPU 使用率飙升。

简单总结：自旋锁适合“锁持有时间极短 + 竞争不激烈”的场景

三、适应性自旋锁：“能总结经验” 的灵活办法

不再固定自旋次数，而是根据以前等待的经验动态调整：

上次自旋成功抢到锁，这次多等会儿（比如从 10 次涨到 20 次），因为大概率锁还是很快释放；
上次自旋没抢到锁，这次少等会儿（比如从 10 次降到 2 次），甚至直接不等（直接阻塞）；
还根据线程竞争激烈程度决定，如果激烈话，直接少等或不等（避免 CPU 被占满）。

举例

还是你买奶茶，但是这次会记着上次的情况来进行灵活调整，不再是“死等”。比如：

①上次前面的人只花 2 秒付款，这次你多等会儿（自旋次数增加）；

②上次前面的人花了 1 分钟，这次你只等 2 秒就去休息区（自旋次数减少）；

③要是排队的人排到门口了，你直接不等了，去休息区（不自旋）。

适应性自旋锁比普通自旋锁灵活，能平衡 CPU 开销和上下文切换开销；JVM 自动调整次数，不用开发者手动设置。

注意事项：

一般 Java 程序员 不会自己写自旋锁。

大部分情况下你用的是：synchronized 关键字；ReentrantLock；其他java.util.concurrent 里的锁