非公平锁的lock()能“插队”是因为在方法开头直接cas抢占，成功即获锁；仅在锁空闲时有效，否则退化为排队逻辑。
非公平锁的 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 <pid></pid>查看带锁信息的完整堆栈，重点关注java.util.concurrent.locks.AbstractQueuedSynchronizer$Node相关帧 - 容易被忽略的地方：线程被唤醒后，在
acquireQueued返回前可能再次被中断，此时会抛InterruptedException并清理节点——这个异常路径常被日志过滤掉
