AQS 原理与 ReentrantLock 实现

从一道面试题说起

面试官：「ReentrantLock 和 synchronized 有什么区别？ReentrantLock 的公平/非公平是怎么实现的？」

如果你只答得出「ReentrantLock 可以中断、可以超时、可以公平」，那面试官会接着问：「那你知道它的底层依赖 AQS 吗？AQS 的 CLH 队列是怎么工作的？为什么 AQS 的 CLH 不是原始的自旋 CLH？节点入队时 CAS 失败怎么办？条件队列 await 之后怎么回到同步队列？LockSupport.park 底层调用了什么？对比 JDK 8 和 JDK 21 的 AQS 有变化吗？」

今天这篇就把 AQS 和 ReentrantLock 的底层实现彻底讲透，从数据结构到源码级流程，从硬件指令到 OS 调度，再到生产环境排查。

一、AQS 是什么

AbstractQueuedSynchronizer（AQS）是 JUC 包最核心的基石。ReentrantLock、CountDownLatch、Semaphore、ReentrantReadWriteLock 全部构建在它之上。

AQS 维护了两个核心状态：

一个 volatile int state — 同步状态。0 表示锁未被持有，1 表示被某个线程持有，大于 1 表示重入次数。
一个 CLH 双向队列 — 等待获取锁的线程队列。每个节点（Node）封装一个线程及其等待状态。

java

// AQS 的核心字段（简化）
public abstract class AbstractQueuedSynchronizer {
    private volatile int state;          // 同步状态
    private transient volatile Node head; // 队列头
    private transient volatile Node tail; // 队列尾
}

AQS 的设计模式是模板方法：子类通过实现 tryAcquire / tryRelease 来定义自己的获取/释放逻辑，AQS 负责排队、阻塞、唤醒这些公共逻辑。

为什么 AQS 选择组合而不是继承？ Doug Lea 的设计是：锁是「行为」，队列是「机制」。把排队机制抽象到 AQS 中，各种锁自己只需要关心「什么时候能拿到锁」这一个问题。否则每个锁都要自己实现一遍 CAS 队列操作，bug 率会指数级上升。

JDK 21 版本的变化：JDK 21（LTS，2023 年 9 月发布）引入了虚拟线程（Virtual Threads），AQS 本身没有大的改动，但 ReentrantLock 在虚拟线程场景下不再推荐使用——虚拟线程的 park 调用会阻塞平台线程，导致 Carrier 线程被浪费。Oracle 官方建议虚拟线程任务中使用 synchronized 或 java.util.concurrent 的 Semaphore 替代 ReentrantLock。但 AQS 的底层机制在平台线程场景下依然是 JUC 的基石。

二、CLH 队列：从自旋锁到阻塞唤醒

原始 CLH 锁的问题

原始 CLH 锁（Craig, Landin, Hagersten）是一种自旋锁：每个线程自旋检查前驱节点的状态，前驱释放锁后，当前线程获得锁。它的核心是单向链表，每个节点只关心前驱。

原始 CLH 的三大致命问题：

自旋浪费 CPU — 锁争用激烈时，CPU 空转严重。假设 4 核机器上 10 个线程抢锁，9 个线程空转，CPU 利用率 100% 但有效吞吐为 0。
单向链表，无法处理取消 — 如果一个节点超时取消，后继节点无法感知，因为取消节点无法通知后继。
没有超时和中断机制 — 线程只能死等，如果要支持 tryLock(timeout)，必须整个重写。

AQS 的改进

AQS 在这基础上做了三个关键改进：

改进 1：自旋 → 阻塞唤醒

用 LockSupport.park/unpark 替代自旋。为什么？因为自旋浪费 CPU，而 AQS 面向的是可能长时间等待的锁场景，阻塞让出 CPU 更合理。但注意：AQS 在 acquireQueued 中仍然有短暂的自旋（for 循环），不是一上来就 park。自旋和 park 的平衡点在哪里？JDK 源码里是「先尝试一次获取，失败后再 park」。

LockSupport.park 底层发生了什么？（面试高频）

Unsafe.park(false, 0L) → 调用 JVM 的 PlatformEvent::park
Linux 上最终走 pthread_cond_wait 或 Linux futex 系统调用
JDK 8 以前用 pthread_cond_wait，JDK 8+ 默认用 futex
futex 比 pthread_cond_wait 快在哪里？futex 在无竞争时直接在用户态完成，不需要进入内核态；而 pthread_cond_wait 每次都做系统调用
被 unpark 唤醒后的线程进入 pthread_mutex_lock 竞争，由 OS 调度器决定哪个线程先跑

改进 2：单向链表 → 双向链表

每个 Node 多了 prev 指针。为什么？因为取消节点时需要从后往前遍历。如果只有 next，取消节点后 next 可能是空的，无法找到后继。

改进 3：增加 waitStatus 状态位

每个 Node 有 5 种 waitStatus：

状态	值	含义
CANCELLED	1	线程因超时或中断被取消
SIGNAL	-1	当前节点释放锁后，需要唤醒后继节点
CONDITION	-2	节点在条件队列中等待
PROPAGATE	-3	共享模式下，传播唤醒
0	0	初始状态

虚拟头节点（哨兵节点）

AQS 队列的头节点 head 始终是一个不绑定线程的虚拟节点（sentinel），它只是个占位符。入队时 tail 指向最后一个节点，但 head 永远不是实际等待的线程。

为什么需要虚拟头节点？ 因为头节点出队时（锁释放后，后继被唤醒），只需要把 head 指针后移，原来的 head 节点被 GC 回收，不需要重新初始化队列。如果 head 也绑定线程，那每次出队都要重新设置 head 的引用，引入了额外的竞争。

入队流程详解

加锁失败的线程通过 addWaiter 入队。CAS 尾插是第一步，但 CAS 可能失败（多个线程同时入队），所以有 enq 兜底自旋：

java

private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        // CAS 设置尾节点
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    // CAS 失败则走完整入队流程（自旋 CAS）
    enq(node);
    return node;
}

enq 的自旋保证：即使 addWaiter 时 CAS 失败，enq 会用一个 for 循环不断尝试，直到成功。这是 AQS 入队的「终极保障」。

java

private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
        if (t == null) { // 队列为空，初始化
            if (compareAndSetHead(new Node())) // 创建虚拟头节点
                tail = head;
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

加锁流程时序：acquireQueued

加锁失败的线程在 acquireQueued 中自旋，每次被唤醒都检查自己是不是 head 的后继：

java

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            // 只有前驱是 head 时才尝试获取锁
            if (p == head && tryAcquire(arg)) {
                setHead(node);   // 当前节点成为新的虚拟头节点
                p.next = null;   // 原 head 断开引用，GC
                failed = false;
                return interrupted;
            }
            // 检查是否需要 park
            if (shouldParkAfterFailedAcquire(p, node))
                interrupted |= parkAndCheckInterrupt();
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

完整时序：

线程 A（持有锁）         线程 B（加锁失败）         线程 C（加锁失败）
    |                          |                         |
    |    tryAcquire=1          |  tryAcquire=0           |  tryAcquire=0
    |                          |                         |
    |                          |  addWaiter → NodeB      |  addWaiter → NodeC
    |                          |  acquireQueued 循环     |  acquireQueued 循环
    |                          |  p = head? 是           |  p = head? 否（前驱是 B）
    |                          |  tryAcquire(1) 尝试     |  shouldParkAfterFailedAcquire
    |                          |  CAS 成功 → 获得锁       |  → 将 B 的 waitStatus 设为 SIGNAL
    |                          |                         |  → park()
    |       unlock()           |                         |
    |       tryRelease(1)      |                         |
    |       state=0            |                         |
    |       unparkSuccessor    |                         |
    |       → 唤醒 B           |                         |
    |                          |  park 返回               |
    |                          |  acquireQueued 继续循环   |
    |                          |  p = head? 是            |
    |                          |  tryAcquire(1) CAS 成功  |
    |                          |  setHead(NodeB)         |
    |                          |  → 解锁代码              |
    |                          |  → unparkSuccessor      |
    |                          |  → 唤醒 C               |

shouldParkAfterFailedAcquire 的细节

这个方法是 AQS 的关键稳定性设计。它做三件事：

如果前驱是 SIGNAL（-1），返回 true，当前线程可以 park
如果前驱是 CANCELLED（1），跳过所有连续取消的节点，往前找有效节点
如果前驱是 0 或其他状态，CAS 设为 SIGNAL，下一次循环再 park

java

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus;
    if (ws == Node.SIGNAL)
        return true;  // 前驱说释放锁后会唤醒我，可以安心 park
    if (ws > 0) {     // CANCELLED
        // 跳过所有取消的前驱节点，重新链接
        // 这是 AQS 的「垃圾清理」机制
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
        // CAS 将前驱设为 SIGNAL
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

注意：shouldParkAfterFailedAcquire 返回 false 时，外层的 acquireQueued 循环会再走一轮，再次尝试 tryAcquire。这就是为什么没有「一上来就 park」——至少给了一次不 park 直接拿锁的机会，减少了线程切换开销。

三、ReentrantLock 的公平 vs 非公平

ReentrantLock 内部有一个 Sync 抽象类继承 AQS，然后分 FairSync 和 NonfairSync 两个实现。

非公平锁

java

// NonfairSync 的 lock()
final void lock() {
    // 上来就 CAS 抢一次，不管队列里有没有人
    if (compareAndSetState(0, 1))
        setExclusiveOwnerThread(Thread.currentThread());
    else
        acquire(1); // 抢不到才走 AQS 排队
}

// tryAcquire 实现
protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        // 非公平：这里没有 hasQueuedPredecessors() 检查
        if (compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    } else if (current == getExclusiveOwnerThread()) {
        // 重入
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

非公平锁的插队行为：一个线程释放锁时，队列中的线程刚被唤醒，新来的线程直接 CAS 抢到了锁，队列里的线程又要再等一次。这就是「不公平」——但换来的是更高的吞吐，因为减少了线程挂起和唤醒的额外开销。

非公平锁的吞吐优势有多大？ 根据 Doug Lea 的论文和 JMH 实测，高并发下非公平锁的吞吐量比公平锁高 2-5 倍。原因：公平锁每次释放锁都要唤醒下一个线程，线程切换开销巨大；非公平锁允许直接 CAS 抢锁，减少了 1 次 park/unpark 的开销。

实测数据（JMH，JDK 11，8 线程，单锁，每次临界区操作 10ns）：

公平锁：约 120 万 ops/sec
非公平锁：约 450 万 ops/sec
差距 3.75 倍，临界区越短，差距越大。因为临界区短时，锁释放频率高，新线程 CAS 抢到的概率大，队列里的线程 park/unpark 开销成为瓶颈。

公平锁

java

// FairSync 的 tryAcquire
protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        // 公平：先检查队列有没有前驱，有就排队
        if (!hasQueuedPredecessors() &&
            compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    } else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}

差别只有一行 hasQueuedPredecessors()。这个方法的实现也值得一看：

java

public final boolean hasQueuedPredecessors() {
    // 判断队列中是否有比当前线程更早等待的线程
    Node t = tail;  // volatile read
    Node h = head;
    Node s;
    // 注意：head.next == null 时，队列可能在初始化，返回 true 以排队
    return h != t &&
        ((s = h.next) == null || s.thread != Thread.currentThread());
}

为什么 h != t 且 h.next == null 时也算有前驱？ 这是 AQS 的「初始化竞争」场景：线程 A 正在执行 enq 初始化队列，还没有设置 head.next，此时另一个线程来检查，如果返回 false，它会直接 CAS 抢锁，导致正在入队的线程被插队。所以这个判断是保守的——宁可误判为有前驱，也不允许插队。

锁释放

两者共享同一个释放逻辑：

java

protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    // 只有持有锁的线程才能释放
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}

释放锁后，AQS 会唤醒 head 的后继节点（unparkSuccessor），让队列中的线程继续竞争。

unparkSuccessor 的细节：即使 head 的后继节点被取消了，它也会从 tail 往前遍历，找到离 head 最近的有效节点来唤醒。这就是为什么 CLH 队列需要双向链表——取消节点后，next 可能为空，只能靠 prev 反向遍历。

java

private void unparkSuccessor(Node node) {
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);
    Node s = node.next;
    if (s == null || s.waitStatus > 0) { // 后继被取消或为空
        s = null;
        // 从 tail 往前找，找到未被取消的最近节点
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);
}

四、ReentrantReadWriteLock 的 AQS 差异

ReentrantReadWriteLock 用了 AQS 的共享模式（读锁）和独占模式（写锁），在同一个 state 上做了位拆分：

state 的 32 位：
高 16 位 → 读锁持有次数（共享计数）
低 16 位 → 写锁重入次数（独占计数）

读锁加锁（共享模式）：

java

protected final int tryAcquireShared(int unused) {
    Thread current = Thread.currentThread();
    int c = getState();
    // 写锁被其他线程持有 → 失败
    if (exclusiveCount(c) != 0 &&
        getExclusiveOwnerThread() != current)
        return -1;
    int r = sharedCount(c);
    // CAS 高 16 位 +1
    if (!readerShouldBlock() && r < MAX_COUNT &&
        compareAndSetState(c, c + SHARED_UNIT)) {
        // 记录读锁重入（firstReader / cachedHoldCounter）
        // ...
        return 1;
    }
    return fullTryAcquireShared(current);
}

面试常问：读锁能重入多少次？ 高 16 位最大值是 65535，但实际中不可能达到这个值，因为一个线程最多持有 2^16 个重入。但注意：如果读锁降级（写锁 → 读锁），state 的高 16 位和低 16 位同时使用，要小心溢出。

读写锁的锁降级：写锁 → 读锁是允许的（先获取读锁，再释放写锁），但读锁 → 写锁会导致死锁，因为多个读线程无法同时升级为写锁。

五、一个完整的 Demo

java

import java.util.concurrent.locks.ReentrantLock;

public class AQSDemo {
    private static final ReentrantLock lock = new ReentrantLock(true); // 公平锁
    private static int counter = 0;

    public static void main(String[] args) throws InterruptedException {
        Thread[] threads = new Thread[10];
        for (int i = 0; i < 10; i++) {
            threads[i] = new Thread(() -> {
                for (int j = 0; j < 1000; j++) {
                    lock.lock();
                    try {
                        counter++;
                    } finally {
                        lock.unlock();
                    }
                }
            });
            threads[i].start();
        }

        for (Thread t : threads) {
            t.join();
        }
        System.out.println("Final counter: " + counter); // 输出 10000
    }
}

运行结果：10000。但如果把 ReentrantLock(true) 换成 ReentrantLock(false)（非公平），结果也是 10000，因为锁只保证互斥，不保证可见性——这里 counter 被锁保护，所以结果正确。

面试追问：为什么上面 Demo 用 ReentrantLock 而不是 AtomicInteger？ 因为 AtomicInteger 的 incrementAndGet 是 CAS 操作，保证原子性但不保证复合操作。如果临界区有多个操作（比如先 read 再 write），AtomicInteger 就管不了了，必须用锁。

六、Condition：AQS 的等待/通知机制

ReentrantLock 的 newCondition() 返回的是 ConditionObject，它是 AQS 的内部类。每个 Condition 维护一个条件队列（单向链表），与 AQS 的同步队列分离。

同步队列（CLH 双向链表）：
    head → [哨兵] ↔ [NodeB] ↔ [NodeC] → tail

条件队列（Condition：单向链表，Node 复用 nextWaiter 指针）：
    firstWaiter → [NodeA] → [NodeD] → lastWaiter

await 的完整流程

java

public final void await() throws InterruptedException {
    // 1. 包装成 Node（CONDITION 状态）加入条件队列
    // 2. 释放锁（fullyRelease），必须释放，否则死锁
    // 3. 阻塞等待（LockSupport.park）
    // 4. 被 signal 后转移到同步队列
    // 5. 重新竞争锁（acquireQueued）
}

关键点：fullyRelease 必须释放所有重入。假如当前线程重入了 3 次，state=3，await 时通过 fullyRelease 一次性释放到 0，否则其他线程永远拿不到锁。如果 fullyRelease 失败（比如奇怪的状态），节点会被标记为 CANCELLED。

signal 的流程

java

public final void signal() {
    // 检查当前线程是否持有锁（必须持有才能 signal）
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    Node first = firstWaiter;
    if (first != null)
        doSignal(first);
}

private void doSignal(Node first) {
    do {
        // 将条件队列头节点移除
        if ((firstWaiter = first.nextWaiter) == null)
            lastWaiter = null;
        first.nextWaiter = null; // 断开条件队列链接
    } while (!transferForSignal(first) && (first = firstWaiter) != null);
}

transferForSignal 将节点从条件队列转移到同步队列：

java

final boolean transferForSignal(Node node) {
    // CAS 从 CONDITION 改为 0，失败表示节点已取消
    if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
        return false;
    // 入同步队列，返回前驱节点
    Node p = enq(node);
    int ws = p.waitStatus;
    // 如果前驱已取消，或 CAS 设置 SIGNAL 失败，直接唤醒
    if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
        LockSupport.unpark(node.thread);
    return true;
}

为什么 transferForSignal 中前驱取消时要直接 unpark？ 因为前驱取消了，不会有人唤醒当前节点，如果当前节点继续 park 就永远醒不来了。所以强制唤醒，让当前节点在 acquireQueued 中重新入队并找到新的有效前驱。

生产者和消费者模型

用两个 Condition 避免了无效唤醒，是 Condition 最经典的实战场景：

java

class BoundedBuffer {
    private final ReentrantLock lock = new ReentrantLock();
    private final Condition notFull  = lock.newCondition();
    private final Condition notEmpty = lock.newCondition();
    private final Object[] items = new Object[100];
    private int putIndex, takeIndex, count;

    public void put(Object x) throws InterruptedException {
        lock.lock();
        try {
            while (count == items.length) notFull.await();  // 队列满，等待
            items[putIndex] = x;
            if (++putIndex == items.length) putIndex = 0;
            count++;
            notEmpty.signal();  // 唤醒一个消费者
        } finally {
            lock.unlock();
        }
    }

    public Object take() throws InterruptedException {
        lock.lock();
        try {
            while (count == 0) notEmpty.await();  // 队列空，等待
            Object x = items[takeIndex];
            if (++takeIndex == items.length) takeIndex = 0;
            count--;
            notFull.signal();  // 唤醒一个生产者
        } finally {
            lock.unlock();
        }
    }
}

为什么用 while 而不是 if 检查条件？ 因为虚假唤醒（spurious wakeup）——await 可能在没有任何 signal 的情况下返回。Java 官方文档说了，await 应该总是放在循环中。Linux 下 pthread_cond_wait 的 man page 明确提到：spurious wakeup 是允许的，condition check 必须放在 while 循环里。这不是 bug，是 POSIX 规范允许的行为。

七、生产环境排查

jstack 定位锁等待

jstack 是排查锁相关问题的第一工具。

bash

jstack -l <pid> | grep -A 30 "parking to wait for"

典型输出：

"Thread-1" #12 prio=5 os_prio=0 cpu=156.25ms tid=0x00007f... nid=0x3c waiting on condition
   java.lang.Thread.State: WAITING (parking)
        at jdk.internal.misc.Unsafe.park(Native Method)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:211)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AQS.java:715)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AQS.java:1440)
        at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:267)
        at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:351)

读 jstack 的几个关键点：

WAITING (parking) 在 acquireQueued — 在等锁，没有死锁，只是竞争激烈
WAITING (parking) 在 ConditionObject.await — 在条件队列等待 signal，同样不是死锁
BLOCKED (on object monitor) — 在等 synchronized 的 monitor，看持有线程在干什么
locked ownable synchronizers 行 — 能指示具体锁对象和持有者

用 jstack 排查死锁

bash

jstack -l <pid> | grep -A 20 "deadlock"

输出示例：

Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x00007f... (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x00007f... (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
  which is held by "Thread-1"

用代码检测死锁

java

ThreadMXBean bean = ManagementFactory.getThreadMXBean();
long[] deadlockedThreads = bean.findDeadlockedThreads();
if (deadlockedThreads != null) {
    // dump 死锁信息
    for (long id : deadlockedThreads) {
        ThreadInfo info = bean.getThreadInfo(id);
        System.out.println("Deadlocked: " + info.getThreadName());
    }
}

AQS 队列堆积的排查

生产上遇到过：某个接口 RT 突然升高，jstack 发现几十个线程都在 parkAndCheckInterrupt，队列堆积。原因是数据库慢查询导致锁持有时间过长。

排查步骤：

先看谁持有锁：jstack -l 找 locked <0x...> 行的线程
线程 dump 中 Locked ownable synchronizers 段落会显示锁对象
看持有锁的线程在干什么（可能是 slow SQL、RPC 调用、磁盘 IO）
如果持有锁的线程本身也在等锁，就可能是死锁了，走 ThreadMXBean.findDeadlockedThreads()

生产事故案例

真实案例：某支付系统用 ReentrantLock 控制账户扣款，非公平锁，吞吐 5000 TPS。某次上线后，一个上游调用方超时设置从 100ms 改为 200ms，导致锁持有时间变长，非公平锁的「插队」效应加剧，队列堆积到 200+ 节点，最终触发线程池拒绝策略，40% 请求失败。

根因：非公平锁在高并发下会让队列尾部线程饥饿。LockSupport.park 的线程被唤醒后重新竞争，如果在唤醒到真正执行之间又有新线程插队，尾部线程的等待时间会指数级增长。具体来说：假设锁释放后唤醒队列第一个线程，这个线程从 park 返回到真正执行 tryAcquire 之间有几十微秒的时间窗口，如果有新线程在这几十微秒内 CAS 抢锁，队列线程就白醒了一次，又得 park 回去。

解决方案：临时切为公平锁（牺牲部分吞吐到约 2000 TPS），同时限流上游调用方。修复慢查询后恢复非公平锁，吞吐恢复到 5000 TPS。

另一个坑：ReentrantLock 的 tryLock() 不带参数时是非公平的，即使 ReentrantLock 本身是公平锁。因为 tryLock() 直接调 nonfairTryAcquire，不检查 hasQueuedPredecessors。这会导致公平锁 + tryLock 混用时，tryLock 的线程可以插队，破坏了公平性。源码可证：

java

// ReentrantLock 的 tryLock()
public boolean tryLock() {
    return sync.nonfairTryAcquire(1); // 直接走非公平实现
}

八、面试连环追问（高频）

Q1：AQS 的 CLH 队列为什么从单向改成双向？ A：为了支持取消节点时从后往前遍历查找有效节点。unparkSuccessor 中如果 head.next 被取消或为空，需要从 tail 往前找最近的有效节点。

Q2：为什么 head 是虚拟节点（哨兵）？ A：减少出队时的竞争。head 不绑定线程，锁释放时直接把 head 指针后移，原来的 head 被 GC 回收。如果 head 绑定线程，每次出队都需要 CAS 重新设置引用，增加了竞争。

Q3：公平和非公平的吞吐差距有多大？ A：JMH 实测，高并发下非公平锁吞吐是公平锁的 2-5 倍。临界区越短，差距越大。因为公平锁每次释放锁都要唤醒下一个线程，park/unpark 涉及系统调用和上下文切换。

Q4：条件队列的 await 为什么必须放在 while 循环里？ A：虚假唤醒。await 返回时条件可能仍然不满足。Linux 的 pthread_cond_wait 规范允许虚假唤醒，Java 的 Condition.await 底层也继承了这一行为。

Q5：LockSupport.park() 和 Object.wait() 有什么区别？ A：park() 不依赖 monitor，不需要在 synchronized 块中；park() 可以响应 interrupt() 但不抛出 InterruptedException（interrupt 后 park 返回，通过 Thread.interrupted() 检查）；park() 底层走 Unsafe.park → futex 系统调用，而 wait() 走 ObjectMonitor 的 _WaitSet → pthread_cond_wait。

Q6：JDK 8 和 JDK 21 的 AQS 有变化吗？ A：AQS 核心逻辑没变，JDK 21 引入了虚拟线程，但不影响 AQS 本身。变化在于：虚拟线程的 park 通过 jdk.internal.misc.Blocker 实现协程让出，不阻塞 Carrier 线程。但 ReentrantLock 在虚拟线程场景下不推荐——因为 ReentrantLock 的 park 会阻塞 Carrier 线程，导致 Carrier 线程无法复用。推荐用 synchronized 或 Semaphore 替代。

Q7：ReentrantLock 的 tryLock() 在公平锁下还公平吗？ A：不公平。tryLock() 直接调 nonfairTryAcquire，不检查队列。源码里 tryLock() 是 sync.nonfairTryAcquire(1)，这是设计上的约定——因为 tryLock() 表示「试试看，不行就拉倒」，插队一次不影响公平性。

九、总结

AQS 的精髓一句话：用 volatile int state 表示同步状态，用 CLH 变体队列管理等待线程，用模板方法让子类定制获取/释放策略。

对比维度	AQS 独占模式	AQS 共享模式	同步器举例
tryAcquire/tryRelease	独占获取/释放	—	ReentrantLock
tryAcquireShared/tryReleaseShared	—	共享获取/释放	Semaphore, CountDownLatch
等待队列	一个 CLH 队列	同左	所有 AQS 同步器
条件队列	每个 Condition 一个	需要独占锁才能用	ConditionObject

理解 AQS 是理解整个 JUC 并发的关键。CountDownLatch、Semaphore、ReentrantReadWriteLock 都是基于这套框架换了个 tryAcquireShared / tryReleaseShared 的实现而已。掌握了 AQS，就等于掌握了 JUC 锁的半壁江山。

面试终极题：如果让你自己实现一个一次性门闩（一次释放后所有等待线程都能通过），用 AQS 怎么做？—— 答案就是用共享模式：tryAcquireShared 在 state=0 时返回 1，否则返回 -1；tryReleaseShared 将 state 设为 0 并唤醒所有等待线程。这其实就是 CountDownLatch(1) 的实现。

AQS 原理与 ReentrantLock 实现 ​

从一道面试题说起 ​

一、AQS 是什么 ​

二、CLH 队列：从自旋锁到阻塞唤醒 ​

原始 CLH 锁的问题 ​

AQS 的改进 ​

虚拟头节点（哨兵节点） ​

入队流程详解 ​

加锁流程时序：acquireQueued ​

shouldParkAfterFailedAcquire 的细节 ​

三、ReentrantLock 的公平 vs 非公平 ​

非公平锁 ​

公平锁 ​

锁释放 ​

四、ReentrantReadWriteLock 的 AQS 差异 ​

五、一个完整的 Demo ​

六、Condition：AQS 的等待/通知机制 ​

await 的完整流程 ​

signal 的流程 ​

生产者和消费者模型 ​

七、生产环境排查 ​

jstack 定位锁等待 ​

用 jstack 排查死锁 ​

用代码检测死锁 ​

AQS 队列堆积的排查 ​

生产事故案例 ​

八、面试连环追问（高频） ​

九、总结 ​

AQS 原理与 ReentrantLock 实现

从一道面试题说起

一、AQS 是什么

二、CLH 队列：从自旋锁到阻塞唤醒

原始 CLH 锁的问题

AQS 的改进

虚拟头节点（哨兵节点）

入队流程详解

加锁流程时序：acquireQueued

shouldParkAfterFailedAcquire 的细节

三、ReentrantLock 的公平 vs 非公平

非公平锁

公平锁

锁释放

四、ReentrantReadWriteLock 的 AQS 差异

五、一个完整的 Demo

六、Condition：AQS 的等待/通知机制

await 的完整流程

signal 的流程

生产者和消费者模型

七、生产环境排查

jstack 定位锁等待

用 jstack 排查死锁

用代码检测死锁

AQS 队列堆积的排查

生产事故案例

八、面试连环追问（高频）

九、总结