ReentrantLock非公平锁源码与CAS抢锁解析

ReentrantLock的非公平锁并非“肆意插队”，而是在调用lock()的瞬间通过一次无条件CAS抢占锁，仅当锁空闲时才发挥“插队”优势，一旦失败便立即退化为与公平锁一致的排队等待机制；其高性能源于避免线程唤醒开销，但设计精妙——重入判断严格依赖exclusiveOwnerThread而非state值，状态更新顺序保障了可重入原子性，入队后行为完全遵循AQS规范，且底层park/unpark机制导致jstack中BLOCKED状态常为误判；理解这些细节，才能避开高并发下因误解“非公平”而导致的性能误判、调试陷阱与线程状态误读。

非公平锁的 lock() 为什么能“插队”？

因为非公平锁在 lock() 方法开头就直接尝试一次 CAS 抢占，不查队列、不等唤醒，成功就立即拿到锁——这是它比公平锁快的核心机制。

这个快速路径只在锁空闲时有效；一旦锁被占用，它就退化为和公平锁一样的入队逻辑。所以“非公平”不是全程乱来，而是仅在获取锁的**第一刻**有插队特权。

• 典型错误现象：Thread A 刚释放锁，Thread B 还没从等待队列中被唤醒，Thread C 就通过 compareAndSetState(0, 1) 抢到了——这不是 bug，是设计如此
• 使用场景：高并发下锁竞争不激烈、或线程唤醒开销显著高于 CAS 开销时（比如临界区极短），非公平锁吞吐更高
• 注意：ReentrantLock 默认构造即非公平，不用显式传 false；公平锁才需 new ReentrantLock(true)

nonfairTryAcquire 里重入判断和状态更新的顺序为什么不能调换？

源码中先用 getExclusiveOwnerThread() == current 判断是否重入，再做 setState(c + acquires)。如果反过来，可能在 CAS 更新 state 后、但还没设置 owner 前发生线程切换，导致锁归属与状态不一致。

这个顺序保障了“可重入性”的原子前提：只有当前线程才能增加锁计数，且每次增加都必须已持有锁。

• 常见错误理解：以为只要 state > 0 就说明有线程持锁——错，state 只是计数，真正标识持有者的是 exclusiveOwnerThread 字段
• 参数差异：acquires 通常为 1（普通 lock()），但 tryLock() 或条件变量唤醒后重入可能传其他值
• 性能影响：两次 volatile 读（getState() 和 getExclusiveOwnerThread()）不可避免，但比加锁后进同步块轻得多

为什么 acquire(1) 在 CAS 失败后不立刻自旋，而是先入队？

因为 AbstractQueuedSynchronizer（AQS）的设计原则是：避免无意义的 CPU 空转。抢占失败后，线程会调用 addWaiter(Node.EXCLUSIVE) 入队，再走 acquireQueued 流程——这期间会检查前驱是否为 head、是否该唤醒自己，而不是死等。

换句话说，非公平 ≠ 一直抢，而是在“刚进来那一下”抢；抢不到，就老老实实排队，该挂起挂起。

• 容易踩的坑：误以为非公平锁会持续自旋重试，导致对锁争用延迟预期错误；实际上入队后的等待行为和公平锁完全一致
• 兼容性注意：JDK 6 引入的 park()/unpark() 是底层挂起原语，不依赖操作系统线程调度策略，因此行为稳定
• 一个关键细节：shouldParkAfterFailedAcquire 会把前驱节点的 waitStatus 设为 -1（SIGNAL）才允许当前线程 park；否则可能重复检查，造成短暂忙等

调试时看到 Thread.getState() == BLOCKED 却没在 acquireQueued 里？

那大概率是线程正卡在 LockSupport.park(this)，但 JVM 线程状态显示为 BLOCKED——这是个常见误导。真实状态其实是 WAITING，只是某些监控工具或 jstack 输出因锁实现细节误判。

验证方法：打印线程堆栈，看顶层是否为 Unsafe.park 或 LockSupport.park；如果是，就是正常阻塞在 AQS 队列里，不是死锁也不是锁泄漏。

• 典型错误归因：把 BLOCKED 状态直接等同于“在 synchronized 等锁”，忽略了 ReentrantLock 底层用的是 park/unpark
• 调试建议：用 jstack -l 查看带锁信息的完整堆栈，重点关注 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node 相关帧
• 容易被忽略的地方：线程被唤醒后，在 acquireQueued 返回前可能再次被中断，此时会抛 InterruptedException 并清理节点——这个异常路径常被日志过滤掉

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