ReentrantLock 源码难不难？“舔狗式等待”你懂了吗？

每个Java程序员在初遇ReentrantLock源码时，都像面对高冷女神的追求者：明明知道它通过AQS队列控制线程等待，可当看到Condition.await()的阻塞逻辑时，总有种”舔狗式等待”的既视感——线程在队列里痴痴地等，却不知道何时能被唤醒。本文将带你看穿源码表象，用工程思维破解这个并发编程的经典难题。

ReentrantLock的Sync抽象类和NonfairSync/FairSync实现类构成了一座技术冰山：

锁获取：tryAcquire()方法仅占源码的5%
排队机制：AQS队列管理占源码的80%
条件变量：ConditionObject实现占剩余的15%

核心难点在于AbstractQueuedSynchronizer（AQS）的双向队列管理：

// 典型入队逻辑
private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    enq(node);
    return node;
}

这个CAS操作就像追求者排队时，既要向前看（prev指针），又要确保自己位置稳固（CAS更新tail），稍有不慎就会引发并发问题。

1. 释放锁：完全释放当前持有的锁
2. 加入条件队列：进入与锁绑定的条件队列
3. 阻塞等待：LockSupport.park()进入等待状态
4. 被唤醒后抢锁：重新竞争锁资源

public class LovePursuitSystem {
    private final Lock lock = new ReentrantLock();
    private final Condition response = lock.newCondition();

    public void waitForResponse() throws InterruptedException {
        lock.lock();
        try {
            while (!isResponseReceived()) {
                response.await(); // 进入"舔狗式等待"
            }
            processResponse();
        } finally {
            lock.unlock();
        }
    }
}

这里的await()就像追求者定时发消息（signal()）却得不到回应，必须等到特定条件（如对方回复）才会结束等待。

断点位置	观察重点
AbstractQueuedSynchronizeracquireQueued	排队线程的自旋逻辑
ConditionObjectawait	条件等待时的状态迁移
AbstractQueuedSynchronizerunparkSuccessor	唤醒后继节点的策略