AbstractQueuedSynchronizer(AQS)

一、简述

AQS，是 JDK 提供的一套用于实现基于 FIFO 等待队列的阻塞锁和相关的同步器的一个同步框架。它使用了一个原子的volatile int state来作为同步器的状态(如：独占锁，1 代表已占有，0 代表未占有)，通过该类提供的原子修改 status 的方法，可以把它作为同步器的基础框架类来实现各种同步器。AQS 还定义了一个实现了 Condition 接口的 ConditionObject 内部类。Condition 将 Object 监视器方法(wait、notify 和 notifyAll)分解成截然不同的对象，以便通过将这些对象与任意 Lock 实现组合使用，为每个对象提供多个等待 set(wait-set)。其中，Lock 替代了 synchronized 方法和语句的使用，Condition 替代了 Object 监视器方法的使用。
简单来说，就是 Condition 提供类似于 Object 的 wait/notify 的功能 await/signal，都是可以使一个正在执行的线程挂起(推迟执行)，直到被其他线程唤醒。但是 Condition 更加强大，如支持多个条件谓词、保证线程唤醒的顺序和在挂起时不需要拥有锁。这个抽象类被设计为作为一些可用原子 int 值来表示状态的同步器的基类。如果有看过类似 CountDownLatch 类的源码实现，会发现其内部有一个继承了 AbstractQueuedSynchronizer 的内部类 Sync。可见 CountDownLatch 是基于 AQS 框架来实现的一个同步器。类似的同步器在 JUC 下还有不少。

AQS 管理一个关于状态信息的单一整数，该整数可以表现任何状态。比如， Semaphore 用它来表现剩余的许可数，ReentrantLock 用它来表现拥有它的线程已经请求了多少次锁；FutureTask 用它来表现任务的状态(尚未开始、运行、完成和取消)。

二、框架

AQS 有两种资源共享方式：Exclusive (独占，只有一个线程能执行，如ReentrantLock)和 Share (共享，多个线程可同时执行，如Semaphore/CountDownLatch)。它维护了一个 volatile int state(代表共享资源)和一个 FIFO 线程等待队列(多线程争用资源被阻塞时会进入此队列)。操作 state 的方法有三个：

  1. getState()
  2. setState()
  3. compareAndSetState()

不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护(如获取资源失败入队/唤醒出队等)，AQS 已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法：

  1. isHeldExclusively()：该线程是否正在独占资源。只有用到 condition 才需要去实现它。
  2. tryAcquire(int)：独占方式。尝试获取资源，返回 boolean 值。
  3. tryRelease(int)：独占方式。尝试获取资源，返回 boolean 值。
  4. tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败；0 表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。
  5. tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回 true，否则返回 false。

以 ReentrantLock 为例，state 初始化为 0，表示未锁定状态。A 线程 lock() 时，会调用 tryAcquire() 独占该锁并将 state+1。此后，其他线程再 tryAcquire() 时就会失败，直到 A 线程 unlock() 到 state=0(即释放锁)为止，其它线程才有机会获取该锁。当然，释放锁之前，A 线程自己可以重复获取该锁(state 会累加)，这就是可重入的概念。获取多少次就要释放多么次，这样才能保证 state 是能回到零态的。

再以 CountDownLatch 为例，任务分为 N 个子线程去执行，state 也初始化为 N (注意 N 要与线程个数一致)。这 N 个子线程是并行执行的，每个子线程执行完后 countDown() 一次，state 会 CAS 减 1。等到所有子线程都执行完后(即 state=0)，会 unpark() 主调用线程，然后主调用线程就会从 await() 函数返回，继续后余动作。

一般来说，自定义同步器要么是独占，要么是共享，它们也只需实现 tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared 中的一种即可。但 AQS 也支持自定义同步器同时实现独占和共享两种方式，如 ReentrantReadWriteLock。

三、acquire() 源码分析

1️⃣AQS 里队列节点 Node 的结构

AQS 的基本执行过程就是尝试获取锁，成功则返回，如果失败就进入同步队列进行锁资源的等待。基于这个流程可以看出队列跟队列中的节点应该是两个重点。首先看下 AQS 里队列节点 Node 的结构，该类中有 5 个字段：

  1. prev/next：指向它的前置节点跟后继节点，由此看出 AQS 中的同步队列是个双向链表。

  2. thread：当前线程对象。

  3. waitStatus：Node 结点是对每一个等待获取资源的线程的封装，其包含了需要同步的线程本身及其等待状态，如是否被阻塞、是否等待唤醒、是否已经被取消等。变量 waitStatus 则表示当前 Node 结点的等待状态，是个 int 类型变量。共有以下 5 种：

注意，负值表示结点处于有效等待状态，而正值表示结点已被取消。所以源码中很多地方用>0、<0来判断结点的状态是否正常。

  1. nextWaiter：如果当前节点是共享模式，该值会指向一个 SHARE 节点。如果当前节点是在条件队列中，则该值会指向下一个等待条件的节点。

2️⃣acquire(int)

此方法是独占模式下线程获取共享资源的顶层入口。如果获取到资源，线程直接返回，否则进入等待队列，直到获取到资源为止，且整个过程忽略中断的影响。这也正是 lock() 的语义，当然不仅仅只限于 lock()。获取到资源后，线程就可以去执行其临界区代码了。下面是 acquire() 的源码：

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(AbstractQueuedSynchronizer.Node.EXCLUSIVE), arg))
        selfInterrupt();
}

该方法流程：
  1. 调用自定义同步器的 tryAcquire() 尝试直接去获取资源，如果成功则直接返回(这里体现了非公平锁，每个线程获取锁时会尝试直接抢占加塞一次，而 CLH 队列中可能还有别的线程在等待)。
  2. 没有成功，addWaiter() 将该线程加入等待队列的尾部，并标记为独占模式。
  3. acquireQueued() 使线程阻塞在等待队列中获取资源，一直获取到资源后才返回。如果在整个等待过程中被中断过，则返回 true，否则返回 false。
  4. 如果线程在等待过程中被中断过，它是不响应的。只是获取资源后才再进行自我中断 selfInterrupt()，将中断补上。

acquire() 的流程也就是ReentrantLock.lock()的流程，查看 lock() 源码，整个函数就是一条 acquire(1)。

3️⃣tryAcquire(int)

此方法尝试去获取独占资源。如果获取成功，则直接返回 true，否则直接返回 false。这也正是 tryLock() 的语义，还是那句话，当然不仅仅只限于 tryLock()。如下是 tryAcquire() 的源码：

protected boolean tryAcquire(int arg) {
    throw new UnsupportedOperationException();
}

直接 throw 异常？这里就体现AQS 只是一个框架，具体资源的获取/释放方式交由自定义同步器去实现这个理念。AQS 这里只定义了一个接口，具体资源的获取交由自定义同步器去实现(通过 state 的 get/set/CAS)。

这里之所以没有定义成 abstract，是因为独占模式下只用实现 tryAcquire-tryRelease，而共享模式下只用实现 tryAcquireShared-tryReleaseShared。如果都定义成 abstract，那么每个模式也要去实现另一模式下的接口。

4️⃣addWaiter(Node)

此方法用于将当前线程加入到等待队列的队尾，并返回当前线程所在的结点。源码如下：

private Node addWaiter(Node mode) {
    //以给定模式构造结点。mode有两种：EXCLUSIVE(独占)和SHARED(共享)
   Node node = new Node(Thread.currentThread(), mode);
    // Try the fast path of enq; backup to full enq on failure
    //尝试快速方式直接放到队尾。
   Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    //上一步失败则通过enq入队。
    enq(node);
    return node;
}

5️⃣enq(Node)

此方法用于将 node 加入队尾。源码如下：

private AbstractQueuedSynchronizer.Node enq(final AbstractQueuedSynchronizer.Node node) {
    for (;;) {
        AbstractQueuedSynchronizer.Node t = tail;
        if (t == null) { // Must initialize
            if (compareAndSetHead(new AbstractQueuedSynchronizer.Node()))
                tail = head;
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

CAS 自旋 volatile 变量，是一种很经典的用法。AtomicInteger.getAndIncrement()源码亦是如此。

6️⃣acquireQueued(Node, int)

通过 tryAcquire() 和 addWaiter()，该线程获取资源失败，已经被放入等待队列尾部了。然后进入等待状态休息，直到其他线程彻底释放资源后唤醒自己，自己再拿到资源，然后就可以去干自己想干的事了。类似于银行排队拿号，在等待队列中排队拿号(中间没其它事干可以休息)，直到拿到号后再返回。该方法非常关键，源码如下：

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;//标记是否成功拿到资源
    try {
        boolean interrupted = false;//标记等待过程中是否被中断过

        //又是一个“自旋”！
        for (;;) {
            final Node p = node.predecessor();//拿到前驱
            //如果前驱是head，即该结点已成老二，那么便有资格去尝试获取资源（可能是老大释放完资源唤醒自己的，当然也可能被interrupt了）。
            if (p == head && tryAcquire(arg)) {
                setHead(node);//拿到资源后，将head指向该结点。所以head所指的标杆结点，就是当前获取到资源的那个结点或null。
                p.next = null; // setHead中node.prev已置为null，此处再将head.next置为null，就是为了方便GC回收以前的head结点。也就意味着之前拿完资源的结点出队了！
                failed = false; // 成功获取资源
                return interrupted;//返回等待过程中是否被中断过
            }

            //如果自己可以休息了，就通过park()进入waiting状态，直到被unpark()。如果不可中断的情况下被中断了，那么会从park()中醒过来，发现拿不到资源，从而继续进入park()等待。
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;//如果等待过程中被中断过，哪怕只有那么一次，就将interrupted标记为true
        }
    } finally {
        if (failed) // 如果等待过程中没有成功获取资源（如timeout，或者可中断的情况下被中断了），那么取消结点在队列中的等待。
            cancelAcquire(node);
    }
}

acquireQueued() 的具体流程：

  1. 结点进入队尾后，检查状态，找到安全休息点。
  2. 调用 park() 进入 waiting 状态，等待 unpark() 或 interrupt() 唤醒自己。
  3. 被唤醒后，看自己是不是有资格能拿到号。如果拿到，head 指向当前结点，并返回从入队到拿到号的整个过程中是否被中断过；如果没拿到，继续流程 1。

7️⃣shouldParkAfterFailedAcquire(Node, Node)

此方法主要用于检查状态，看看自己是否真的可以去休息了(进入 waiting 状态)：

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus;//拿到前驱的状态
    if (ws == Node.SIGNAL)
        //如果已经告诉前驱拿完号后通知自己一下，那就可以安心休息了
        return true;
    if (ws > 0) {
        /*
         * 如果前驱放弃了，那就一直往前找，直到找到最近一个正常等待的状态，并排在它的后边。
         * 注意：那些放弃的结点，由于被自己“加塞”到它们前边，它们相当于形成一个无引用链，稍后就会被保安大叔赶走了(GC回收)！
         */
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
         //如果前驱正常，那就把前驱的状态设置成SIGNAL，告诉它拿完号后通知自己一下。有可能失败，人家说不定刚刚释放完呢！
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

整个流程中，如果前驱结点的状态不是 SIGNAL，那么自己就不能安心去休息，需要去找个安心的休息点，同时可以再尝试下看有没有机会轮到自己拿号。

8️⃣parkAndCheckInterrupt()

如果线程找好安全休息点后，那就可以安心去休息了。此方法就是让线程去休息，真正进入等待状态。

private final boolean parkAndCheckInterrupt() {
    LockSupport.park(this);
    return Thread.interrupted();
}

park() 会让当前线程进入 waiting 状态。在此状态下，有两种途径可以唤醒该线程：

  1. 被 unpark()。
  2. 被 interrupt()。需要注意的是，Thread.interrupted() 会清除当前线程的中断标记位。

四、release(int) 源码分析

1️⃣release(int)

acquire() 的反操作。此方法是独占模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了(即 state=0)，它会唤醒等待队列里的其他线程来获取资源。这也正是 unlock() 的语义，当然不仅仅只限于 unlock()。release() 源码：

public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;//找到头结点
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);//唤醒等待队列里的下一个线程
        return true;
    }
    return false;
}

逻辑并不复杂。它调用 tryRelease() 来释放资源。有一点需要注意的是，它是根据 tryRelease() 的返回值来判断该线程是否已经完成释放掉资源了。所以自定义同步器在设计 tryRelease() 的时候要明确这一点。

2️⃣tryRelease(int)

此方法尝试去释放指定量的资源。源码：

protected boolean tryRelease(int arg) {
    throw new UnsupportedOperationException();
}

跟 tryAcquire() 一样，该方法是需要独占模式的自定义同步器去实现的。正常来说，tryRelease() 都会成功的，因为这是独占模式，该线程来释放资源，那么它肯定已经拿到独占资源了，直接减掉相应量的资源即可(state-=arg)，也不需要考虑线程安全的问题。但要注意它的返回值，上面已经提到了，release() 是根据 tryRelease() 的返回值来判断该线程是否已经完成释放掉资源了。所以自义定同步器在实现时，如果已经彻底释放资源(state=0)，要返回 true，否则返回 false。

3️⃣unparkSuccessor(Node)

此方法用于唤醒等待队列中下一个线程。源码：

private void unparkSuccessor(Node node) {
    //这里，node一般为当前线程所在的结点。
    int ws = node.waitStatus;
    if (ws < 0)//置零当前线程所在的结点状态，允许失败。
        compareAndSetWaitStatus(node, ws, 0);

    Node s = node.next;//找到下一个需要唤醒的结点s
    if (s == null || s.waitStatus > 0) {//如果为空或已取消
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev) // 从后向前找。
            if (t.waitStatus <= 0)//从这里可以看出，<=0的结点，都是还有效的结点。
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);//唤醒
}

方法并不复杂。一句话概括：用 unpark() 唤醒等待队列中最前边的那个未放弃线程，这里也用 s 表示。此时，再和 acquireQueued() 联系起来，s 被唤醒后，进入if (p == head && tryAcquire(arg))的判断(即使 p!=head 也没关系，它会再进入 shouldParkAfterFailedAcquire() 寻找一个安全点。这里既然 s 已经是等待队列中最前边的那个未放弃线程了，那么通过 shouldParkAfterFailedAcquire() 的调整，s 也必然会跑到 head 的 next 结点，下一次自旋 p==head 就成立啦)，然后 s 把自己设置成 head 标杆结点，表示自己已经获取到资源了，acquire() 也返回了。

4️⃣小结

release() 是独占模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果彻底释放了(即state=0)，它会唤醒等待队列里的其他线程来获取资源。

如果获取锁的线程在 release 时异常了，没有 unpark 队列中的其他结点，这时队列中的其他结点会怎么办？是不是没法再被唤醒了？答案是的。此时，队列中等待锁的线程将永远处于 park 状态，无法再被唤醒。但是再回头想想，获取锁的线程在什么情形下会 release 抛出异常呢？

  1. 线程突然死掉了？可以通过 thread.stop 来停止线程的执行，但该函数的执行条件要严苛的多，而且方法注明是非线程安全的，已经标明 Deprecated。
  2. 线程被 interupt 了？线程在运行态是不响应中断的，所以也不会抛出异常；
  3. release 代码有 bug，抛出异常了？目前来看，Doug Lea 的 release 方法还是比较健壮的，没有看出能引发异常的情形。除非自己写的 tryRelease() 有 bug，那就没啥说的，自己写的 bug 只能自己含着泪去承受了。

五、acquireShared(int)源码分析

1️⃣acquireShared(int)

此方法是共享模式下线程获取共享资源的顶层入口。它会获取指定量的资源，获取成功则直接返回，获取失败则进入等待队列，直到获取到资源为止，整个过程忽略中断。acquireShared() 的源码如下：

public final void acquireShared(int arg) {
    if (tryAcquireShared(arg) < 0)
        doAcquireShared(arg);
}

这里 tryAcquireShared() 依然需要自定义同步器去实现。但是 AQS 已经把其返回值的语义定义好了：负值代表获取失败；0 代表获取成功，但没有剩余资源；正数表示获取成功，还有剩余资源，其他线程还可以去获取。所以 acquireShared() 的流程就是：

  1. tryAcquireShared()尝试获取资源，成功则直接返回；
  2. 失败则通过doAcquireShared()进入等待队列park()，直到被unpark()/interrupt()并成功获取到资源才返回。整个等待过程也是忽略中断的。其实跟 acquire() 的流程大同小异，只不过多了个自己拿到资源后，还会去唤醒后继队友的操作(共享)。

2️⃣doAcquireShared(int)

此方法用于将当前线程加入等待队列尾部休息，直到其他线程释放资源唤醒自己，自己成功拿到相应量的资源后才返回。源码：

private void doAcquireShared(int arg) {
    final Node node = addWaiter(Node.SHARED);//加入队列尾部
    boolean failed = true;//是否成功标志
    try {
        boolean interrupted = false;//等待过程中是否被中断过的标志
        for (;;) {
            final Node p = node.predecessor();//前驱
            if (p == head) {//如果到head的下一个，因为head是拿到资源的线程，此时node被唤醒，很可能是head用完资源来唤醒自己的
                int r = tryAcquireShared(arg);//尝试获取资源
                if (r >= 0) {//成功
                    setHeadAndPropagate(node, r);//将head指向自己，还有剩余资源可以再唤醒之后的线程
                    p.next = null; // help GC
                    if (interrupted)//如果等待过程中被打断过，此时将中断补上。
                        selfInterrupt();
                    failed = false;
                    return;
                }
            }

            //判断状态，寻找安全点，进入waiting状态，等着被unpark()或interrupt()
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

跟 acquireQueued() 很相似，流程并没有太大区别。只不过这里将补中断的 selfInterrupt() 放到 doAcquireShared() 里了，而独占模式是放到 acquireQueued() 之外，其实都一样，不知道 Doug Lea 是怎么想的。

跟独占模式比，还有一点需要注意的是，这里只有线程是 head.next 时(“老二”)，才会去尝试获取资源，有剩余的话还会唤醒之后的队友。那么问题就来了，假如老大用完后释放了 5 个资源，而老二需要 6 个，老三需要 1 个，老四需要 2 个。老大先唤醒老二，老二一看资源不够，他是把资源让给老三呢，还是不让？答案是否定的！老二会继续 park() 等待其他线程释放资源，也更不会去唤醒老三和老四了。独占模式，同一时刻只有一个线程去执行，这样做未尝不可；但共享模式下，多个线程是可以同时执行的，现在因为老二的资源需求量大，而把后面量小的老三和老四也都卡住了。当然，这并不是问题，只是 AQS 保证严格按照入队顺序唤醒罢了(保证公平，但降低了并发)。

3️⃣setHeadAndPropagate(Node, int)

private void setHeadAndPropagate(Node node, int propagate) {
    Node h = head;
    setHead(node);//head指向自己
     //如果还有剩余量，继续唤醒下一个邻居线程
    if (propagate > 0 || h == null || h.waitStatus < 0) {
        Node s = node.next;
        if (s == null || s.isShared())
            doReleaseShared();
    }
}

此方法在 setHead() 的基础上多了一步，就是自己苏醒的同时，如果条件符合(比如还有剩余资源)，还会去唤醒后继结点，毕竟是共享模式！

六、releaseShared()源码分析

1️⃣releaseShared()

acquireShared() 的反操作。该方法是共享模式下线程释放共享资源的顶层入口。它会释放指定量的资源，如果成功释放且允许唤醒等待线程，它会唤醒等待队列里的其他线程来获取资源。releaseShared() 的源码：

public final boolean releaseShared(int arg) {
    if (tryReleaseShared(arg)) {//尝试释放资源
        doReleaseShared();//唤醒后继结点
        return true;
    }
    return false;
}

此方法的流程也比较简单，一句话：释放掉资源后，唤醒后继。跟独占模式下的 release() 相似，但有一点稍微需要注意：独占模式下的 tryRelease() 在完全释放掉资源(state=0)后，才会返回 true 去唤醒其他线程，这主要是基于独占下可重入的考量；而共享模式下的 releaseShared() 则没有这种要求，共享模式实质就是控制一定量的线程并发执行，那么拥有资源的线程在释放掉部分资源时就可以唤醒后继等待结点。例如，资源总量是 13，A(5) 和 B(7)分别获取到资源并发运行，C(4) 来时只剩 1 个资源就需要等待。A 在运行过程中释放掉 2 个资源量，然后 tryReleaseShared(2) 返回 true 唤醒 C，C 一看只有 3 个仍不够继续等待；随后 B 又释放 2 个，tryReleaseShared(2) 返回 true 唤醒 C，C 一看有 5 个够自己用了，然后 C 就可以跟 A 和 B 一起运行。而 ReentrantReadWriteLock 读锁的 tryReleaseShared() 只有在完全释放掉资(state=0)才返回 true，所以自定义同步器可以根据需要决定 tryReleaseShared() 的返回值。

2️⃣doReleaseShared()

此方法主要用于唤醒后继。源码如下：

private void doReleaseShared() {
    for (;;) {
        Node h = head;
        if (h != null && h != tail) {
            int ws = h.waitStatus;
            if (ws == Node.SIGNAL) {
                if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                    continue;
                unparkSuccessor(h);//唤醒后继
            }
            else if (ws == 0 &&
                     !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                continue;
        }
        if (h == head)// head发生变化
            break;
    }
}

3️⃣小结

acquire() 和 acquireShared() 两种方法下，线程在等待队列中都是忽略中断的。AQS 也支持响应中断，acquireInterruptibly()/acquireSharedInterruptibly() 即是，相应的源码跟 acquire()和acquireShared() 差不多。

七、简单应用

以 AQS 源码里的 Mutex(互斥锁) 为例，讲一下 AQS 的简单应用。

Mutex 是一个不可重入的互斥锁实现。锁资源(AQS 里的 state)只有两种状态：0 表示未锁定，1 表示锁定。Mutex 的核心源码：

class Mutex implements Lock, java.io.Serializable {
    // 自定义同步器
    private static class Sync extends AbstractQueuedSynchronizer {
        // 判断是否锁定状态
        protected boolean isHeldExclusively() {
            return getState() == 1;
        }

        // 尝试获取资源，立即返回。成功则返回true，否则false。
        public boolean tryAcquire(int acquires) {
            assert acquires == 1; // 这里限定只能为1个量
            if (compareAndSetState(0, 1)) {//state为0才设置为1，不可重入！
                setExclusiveOwnerThread(Thread.currentThread());//设置为当前线程独占资源
                return true;
            }
            return false;
        }

        // 尝试释放资源，立即返回。成功则为true，否则false。
        protected boolean tryRelease(int releases) {
            assert releases == 1; // 限定为1个量
            if (getState() == 0)//既然来释放，那肯定就是已占有状态了。只是为了保险，多层判断！
                throw new IllegalMonitorStateException();
            setExclusiveOwnerThread(null);
            setState(0);//释放资源，放弃占有状态
            return true;
        }
    }

    // 真正同步类的实现都依赖继承于AQS的自定义同步器！
    private final Sync sync = new Sync();

    //lock<-->acquire。两者语义一样：获取资源，即便等待，直到成功才返回。
    public void lock() {
        sync.acquire(1);
    }

    //tryLock<-->tryAcquire。两者语义一样：尝试获取资源，要求立即返回。成功则为true，失败则为false。
    public boolean tryLock() {
        return sync.tryAcquire(1);
    }

    //unlock<-->release。两者语文一样：释放资源。
    public void unlock() {
        sync.release(1);
    }

    //锁是否占有状态
    public boolean isLocked() {
        return sync.isHeldExclusively();
    }
}

同步类在实现时一般都将自定义同步器(sync)定义为内部类，供自己使用；而同步类自己(Mutex)则实现某个接口，对外服务。当然，接口的实现要直接依赖 sync，它们在语义上也存在某种对应关系！！而 sync 只用实现资源 state 的获取-释放方式 tryAcquire-tryRelelase，至于线程的排队、等待、唤醒等，上层的 AQS 都已经实现好了，不用关心。

除了 Mutex，ReentrantLock/CountDownLatch/Semphore 这些同步类的实现方式都差不多，不同的地方就在获取-释放资源的方式 tryAcquire-tryRelelase。掌握了这点，AQS 的核心便被攻破了。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 216,544评论 6赞 501
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 92,430评论 3赞 392
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 162,764评论 0赞 353
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 58,193评论 1赞 292
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 67,216评论 6赞 388
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 51,182评论 1赞 299
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 40,063评论 3赞 418
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,917评论 0赞 274
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 45,329评论 1赞 310
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,543评论 2赞 332
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,722评论 1赞 348
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 35,425评论 5赞 343
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 41,019评论 3赞 326
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,671评论 0赞 22
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,825评论 1赞 269
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,729评论 2赞 368
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,614评论 2赞 353

推荐阅读更多精彩内容