Java自旋锁：while与AtomicReference实现解析

本文深入剖析了Java中自旋锁的正确实现要点，指出盲目使用while(true)或普通布尔变量会导致CPU空转和内存可见性失效，并强调必须依托AtomicReference或AtomicInteger等原子类提供的happens-before语义来保障状态读写的线程安全；同时详解了CAS抢锁的合理退避策略（如Thread.onSpinWait）、解锁时应避免无谓的compareAndSet而改用set或lazySet，以及自旋锁仅适用于极短临界区、高竞争低延迟场景的关键适用边界——真正考验开发者功力的，不是写出循环，而是基于实测数据精准判断“此刻是否值得自旋”。

自旋锁为什么不能直接用 while(true)

因为死循环会吃满 CPU，且没有内存可见性保障。Java 中的普通变量在多线程下可能被缓存到寄存器或 CPU 本地缓存，while(flag == false) 可能永远不退出，哪怕另一个线程已把 flag 设为 true。

必须配合 volatile 或原子类的内存语义——AtomicReference 的 get() 和 compareAndSet() 都有 happens-before 保证，能强制读取主内存最新值。

• 别手写 while(flag) + 普通布尔变量，这是最常见翻车点
• AtomicReference 不推荐：装箱开销大，且布尔值本身无法体现“锁状态”的原子切换意图
• 更合适的是用 AtomicReference 或 AtomicInteger 表示持有者/计数

compareAndSet() 是核心，但不是万能的

自旋锁靠反复尝试 compareAndSet(null, currentThread) 来抢锁。成功即获得锁；失败就继续循环。但要注意：

• 失败后不能立刻重试，否则在高竞争下造成大量 CAS 失败和总线争用，拖慢所有线程
• 建议加入简单退避：比如 Thread.onSpinWait()（JDK9+），或短睡眠 Thread.yield()，甚至小次数的 LockSupport.parkNanos(1)
• compareAndSet() 返回 false 不代表锁被别人长期持有，可能是伪共享、缓存未及时同步，或只是瞬时竞争

示例关键逻辑：

while (!state.compareAndSet(null, Thread.currentThread())) {
    Thread.onSpinWait(); // JDK9+ 推荐，比空转友好
}

解锁必须用 set() 或 lazySet()，不能用 compareAndSet(old, null)

解锁是单线程行为（只有持有者能解），不需要原子性验证。用 compareAndSet(currentThread, null) 多此一举，还可能因线程对象被 GC 或复用导致误判。

• 正确做法：state.set(null) 或更轻量的 state.lazySet(null)（避免写屏障，适合单写场景）
• 如果用了 AtomicInteger 做状态（0=空闲，1=占用），解锁就是 state.set(0)
• 千万别在解锁时检查当前线程是否匹配——这反而引入不必要的分支和内存读，且破坏了“解锁只由持有者执行”的前提

自旋锁不适合长时间持锁或低频竞争场景

它本质是用 CPU 时间换上下文切换开销。一旦临界区稍长（比如 > 几百纳秒），或者锁竞争不激烈，自旋就纯属浪费资源。

• 典型适用场景：锁住极短操作，如更新一个计数器、修改一个标志位、无锁队列的 head/tail 指针调整
• 不适用场景：IO 等待、数据库查询、任意可能阻塞或耗时的操作
• 生产环境慎用裸自旋锁；优先考虑 java.util.concurrent.locks.StampedLock 的乐观读，或 ReentrantLock 的 tryLock() 配合退避策略

真正难的不是写出来，而是判断「此刻该不该自旋」——这得看热点路径的实测延迟分布，而不是凭感觉。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~