Jdk1.5开始引入了j.u.c包，这个包提供了一系列支持并发的组件。这些组件是一系列的同步器，这些同步器主要维护着以下几个功能：内部同步状态的管理(例如表示一个锁的状态是获取还是释放)，同步状态的更新和检查操作，且至少有一个方法会导致调用线程在同步状态被获取时阻塞，以及在其他线程改变这个同步状态时解除线程的阻塞。
上述的这些的实际例子包括：互斥排它锁的不同形式、读写锁、信号量、屏障、Future、事件指示器以及传送队列等。
几乎任一同步器都可以用来实现其他形式的同步器。例如，可以用可重入锁实现信号量或者用信号量实现可重入锁。但是，这样做带来的复杂性、开销及不灵活使j.u.c最多只能是一个二流工程，且缺乏吸引力。
如果任何这样的构造方式不能在本质上比其他形式更简洁，那么开 发者就不应该随意地选择其中的某个来构建另一个同步器。因此，JSR166基于AQS类建立了一个小框架，这个框架为构造同步器提供一种通用的机制，并且被j.u.c包中大部分类使用，同时很多用户也可以用它来定义自己的同步器。
同步器的核心方法是acquire和release操作，其背后的思想也比较简洁明确。acquire操作是这样的：
while (当前同步器的状态不允许获取操作) { 如果当前线程不在队列中，则将其插入队列 阻塞当前线程 }如果线程位于队列中，则将其移出队列
release操作是这样的：
更新同步器的状态 if (新的状态允许某个被阻塞的线程获取成功) 解除队列中一个或多个线程的阻塞状态从这两个操作中的思想中我们可以提取出三大关键操作：同步器的状态变更、线程阻塞和释放、插入和移出队列。所以为了实现这两个操作，需要协调三大关键操作引申出来的三个基本组件：
同步器状态的原子性管理；
线程阻塞与解除阻塞；
队列的管理；
AQS类使用单个int（32位）来保存同步状态，并暴露出getState、setState以及compareAndSet操作来读取和更新这个同步状态。其中属性state被声明为volatile，并且通过使用CAS指令来实现compareAndSetState，使得当且仅当同步状态拥有一个一致的期望值的时候，才会被原子地设置成新值，这样就达到了同步状态的原子性管理，确保了同步状态的原子性、可见性和有序性。
基于AQS的具体实现类（如锁、信号量等）必须根据暴露出的状态相关的方法定义tryAcquire和tryRelease方法，以控制acquire和release操作。当同步状态满足时，tryAcquire方法必须返回true，而当新的同步状态允许后续acquire时，tryRelease方法也必须返回true。这些方法都接受一个int类型的参数用于传递想要的状态。
直到JSR166，阻塞线程和解除线程阻塞都是基于Java的内置管程，没有其它非基于Java内置管程的API可以用来达到阻塞线程和解除线程阻塞。唯一可以选择的是Thread.suspend和Thread.resume，但是它们都有无法解决的竞态问题，所以也没法用，目前该方法基本已被抛弃。具体不能用的原因可以官方给出的答复。
j.u.c.locks包提供了LockSupport类来解决这个问题。方法LockSupport.park阻塞当前线程直到有个LockSupport.unpark方法被调用。unpark的调用是没有被计数的，因此在一个park调用前多次调用unpark方法只会解除一个park操作。另外，它们作用于每个线程而不是每个同步器。一个线程在一个新的同步器上调用park操作可能会立即返回，因为在此之前可以有多余的unpark操作。但是，在缺少一个unpark操作时，下一次调用park就会阻塞。虽然可以显式地取消多余的unpark调用，但并不值得这样做。在需要的时候多次调用park会更高效。park方法同样支持可选的相对或绝对的超时设置，以及与JVM的Thread.interrupt结合 ，可通过中断来unpark一个线程。
整个框架的核心就是如何管理线程阻塞队列，该队列是严格的FIFO队列，因此不支持线程优先级的同步。同步队列的最佳选择是自身没有使用底层锁来构造的非阻塞数据结构，业界主要有两种选择，一种是MCS锁，另一种是CLH锁。其中CLH一般用于自旋，但是相比MCS，CLH更容易实现取消和超时，所以同步队列选择了CLH作为实现的基础。
CLH队列实际并不那么像队列，它的出队和入队与实际的业务使用场景密切相关。它是一个链表队列，通过AQS的两个字段head（头节点）和tail（尾节点）来存取，这两个字段是volatile类型，初始化的时候都指向了一个空节点。如下图： 入队操作：CLH队列是FIFO队列，故新的节点到来的时候，是要插入到当前队列的尾节点之后。试想一下，当一个线程成功地获取了同步状态，其他线程将无法获取到同步状态，转而被构造成为节点并加入到同步队列中，而这个加入队列的过程必须要保证线程安全，因此同步器提供了一个CAS方法，它需要传递当前线程“认为”的尾节点和当前节点，只有设置成功后，当前节点才正式与之前的尾节点建立关联。入队操作示意图大致如下：
出队操作：因为遵循FIFO规则，所以能成功获取到AQS同步状态的必定是首节点，首节点的线程在释放同步状态时，会唤醒后续节点，而后续节点会在获取AQS同步状态成功的时候将自己设置为首节点。设置首节点是由获取同步成功的线程来完成的，由于只能有一个线程可以获取到同步状态，所以设置首节点的方法不需要像入队这样的CAS操作，只需要将首节点设置为原首节点的后续节点同时断开原节点、后续节点的引用即可。出队操作示意图大致如下：
队列的管理除了有同步队列，还有条件队列。AQS只有一个同步队列，但是可以有多个条件队列。AQS框架提供了一个ConditionObject类，给维护独占同步的类以及实现Lock接口的类使用。
ConditionObject类和AQS共用了内部节点，有自己单独的条件队列。signal操作是通过将节点从条件队列转移到同步队列中来实现的，没有必要在需要唤醒的线程重新获取到锁之前将其唤醒。signal操作大致示意图如下：
await操作就是当前线程节点从同步队列进入条件队列进行等待，大致示意图如下：
主要通过独占式同步状态的获取和释放、共享式同步状态的获取和释放来看下AQS是如何实现的。
独占式同步状态调用的方法是acquire，代码如下：
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }上述代码主要完成了同步状态获取、节点构造、加入同步队列以及在同步队列中自旋等待的相关工作，其主要逻辑是：首先调用子类实现的tryAcquire方法，该方法保证线程安全的获取同步状态，如果同步状态获取失败，则构造独占式同步节点（同一时刻只能有一个线程成功获取同步状态）并通过addWaiter方法将该节点加入到同步队列的尾部，最后调用acquireQueued方法，使得该节点以自旋的方式获取同步状态。如果获取不到则阻塞节点中的线程，而被阻塞线程的唤醒主要依靠前驱节点的出队或阻塞线程被中断来实现。
AQS内部Head节点本身不保存等待线程的信息，它通过next变量指向第一个保存线程等待信息的节点(Node1)。当线程被唤醒后，会删除Head节点，而唤醒线程所在的节点会设置为Head节点。
在acquireQueued中，如果线程是因为中断而退出的阻塞状态会返回true，selfInterrupt主要是为了恢复线程的中断状态。
addWaiter传入的是Node.EXCLUSIVE，表明当前的是独占模式。
下面是addWaiter的具体实现：
private Node addWaiter(Node mode) { Node node = new Node(Thread.currentThread(), mode); // tail 指向同步队列的尾节点 Node pred = tail; // Try the fast path of enq; backup to full enq on failure if (pred != null) { node.prev = pred; if (compareAndSetTail(pred, node)) { pred.next = node; return node; } } enq(node); return node; }分析：第一次tail = null, pred = null, 所以进入enq(node)
同步队列采用的懒初始化（lazily initialized）的方式， 初始时 head 和 tail 都会被设置为 null，当一次被访问时 才会创建 head 对象，并把尾指针指向 head。
private Node enq(final Node node) { // 无限循环，直到设置成功返回 for (;;) { Node t = tail; // 同步队列采用的懒初始化（lazily initialized）的方式， // 初始时 head 和 tail 都会被设置为 null，当一次被访问时 // 才会创建 head 对象，并把尾指针指向 head。 if (t == null) { // Must initialize if (compareAndSetHead(new Node())) tail = head; } else { node.prev = t; if (compareAndSetTail(t, node)) { t.next = node; return t; } } } }分析：Node1进入
分析：Node2进入
addWaiter 仅仅是将节点加到了同步队列的末尾，并没有阻塞线程，线程阻塞的操作是在 acquireQueued 方法中完成的，下面是 acquireQueued 的实现：
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)) { // 成功获得锁，将当前节点置为 head 节点，同时删除原 head 节点 setHead(node); p.next = null; // help GC failed = false; return interrupted; } // shouldParkAfterFailedAcquire 检查是否可以挂起线程， // 如果可以挂起进程，会调用 parkAndCheckInterrupt 挂起线程， // 如果 parkAndCheckInterrupt 返回 true，表明当前线程是因为中断而退出挂起状态的， // 所以要将 interrupted 设为 true，表明当前线程被中断过 if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } }acquireQueued 会首先检查当前节点的前继节点是否为 head，如果为 head，将使用自旋的方式不断的请求锁，如果不是 head，则调用 shouldParkAfterFailedAcquire 查看是否应该挂起当前节点关联的线程，下面是 shouldParkAfterFailedAcquire 的实现：
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { // 当前节点的前继节点的等待状态 int ws = pred.waitStatus; // 如果前继节点的等待状态为 SIGNAL 我们就可以将当前节点对应的线程挂起 if (ws == Node.SIGNAL) return true; if (ws > 0) { // ws 大于 0，表明当前线程的前继节点处于 CANCELED 的状态， // 所以我们需要从当前节点开始往前查找，直到找到第一个不为 // CAECELED 状态的节点 do { node.prev = pred = pred.prev; } while (pred.waitStatus > 0); pred.next = node; } else { /* * waitStatus must be 0 or PROPAGATE. Indicate that we * need a signal, but don't park yet. Caller will need to * retry to make sure it cannot acquire before parking. */ compareAndSetWaitStatus(pred, ws, Node.SIGNAL); } return false; }shouldParkAfterFailedAcquire 会检查前继节点的等待状态，如果前继节点状态为 SIGNAL，则可以将当前节点关联的线程挂起，如果不是 SIGNAL，会做一些其他的操作，在当前循环中不会挂起线程。如果确定了可以挂起线程，就调用 parkAndCheckInterrupt 方法对线程进行阻塞：
private final boolean parkAndCheckInterrupt() { // 挂起当前线程 LockSupport.park(this); // 可以通过调用 interrupt 方法使线程退出 park 状态， // 为了使线程在后面的循环中还可以响应中断，会重置线程的中断状态。 // 这里使用 interrupted 会先返回线程当前的中断状态，然后将中断状态重置为 false， // 线程的中断状态会返回给上层调用函数，在线程获得锁后， // 如果发现线程曾被中断过，会将中断状态重新设为 true return Thread.interrupted(); }分析：如果Node1获取到了锁：
原来的状态变更为:
关于是否应该挂起节点的分析
Node1进入shouldParkAfterFailedAcquire:前继节点Dummy Node: waitStatus = 0, 进入else，设置DummyNode的waitStatus = SIGNAL
再次for循环时，Node1将会被挂起，因为其前置节点的waitStatus:SIGNAL
同样地Node2节点也会被挂起
volatile int waitStatus; // 线程状态，总共有四种
CANCELED： 1，因为等待超时 （timeout）或者中断（interrupt），节点会被置为取消状态。 处于取消状态的节点不会再去竞争锁，也就是说不会再被阻塞。节点会一直保持取消状态，而不会转换为其他状态。处于 CANCELED 的节点会被移出队列，被 GC 回收。
SIGNAL： -1，表明当前的后继结点正在或者将要被阻塞（通过使用 LockSupport.pack 方法），因此当前的节点被释放（release）或者被取消时（cancel）时，要唤醒它的后继结点（通过 LockSupport.unpark 方法）。
CONDITION： -2，表明当前节点在条件队列中，因为等待某个条件而被阻塞。
PROPAGATE： -3，在共享模式下，可以认为资源有多个，因此当前线程被唤醒之后，可能还有剩余的资源可以唤醒其他线程。该状态用来表明后续节点会传播唤醒的操作。需要注意的是只有头节点才可以设置为该状态（This is set (for head node only) in doReleaseShared to ensure propagation continues, even if other operations have since intervened.）。
0：新创建的节点会处于这种状态
下面是获取独占锁的流程图：
在独占模式下释放锁时，是没有其他线程竞争的，所以处理会简单一些。首先尝试释放锁，如果失败就直接返回（失败不是因为多线程竞争，而是线程本身就不拥有锁）。如果成功的话，会检查 h 的状态，然后调用 unparkSuccessor 方法来唤醒后续线程。下面是 unparkSuccessor 的实现：
private void unparkSuccessor(Node node) { int ws = node.waitStatus; // 将 head 节点的状态置为 0，表明当前节点的后续节点已经被唤醒了， // 不需要再次唤醒，修改 ws 状态主要作用于 release 的判断 if (ws < 0) compareAndSetWaitStatus(node, ws, 0); /* * Thread to unpark is held in successor, which is normally * just the next node. But if cancelled or apparently null, * traverse backwards from tail to find the actual * non-cancelled successor. */ Node s = node.next; // 如果发现头节点的后继结点为 null 或者处于 CANCELED 状态， // 会从尾部往前找（在节点存在的前提下，这样一定能找到）离头节点最近的需要唤醒的节点，然后唤醒该节点。 if (s == null || s.waitStatus > 0) { s = null; for (Node t = tail; t != null && t != node; t = t.prev) if (t.waitStatus <= 0) s = t; } if (s != null) LockSupport.unpark(s.thread); }独占锁的流程和原理比较容易理解，因为只有一个锁，但是共享锁的处理就相对复杂一些了。在独占锁中，只有在释放锁之后，才能唤醒等待的线程，而在共享模式中，获取锁和释放锁之后，都有可能唤醒等待的线程。如果想要理清共享锁的工作过程，必须将共享锁的获取和释放结合起来看。这里我们先看一下共享锁的释放过程，只有明白了释放过程做了哪些工作，才能更好的理解获取锁的过程。
下面是释放共享锁的流程：
通过 releaseShared 方法会释放共享锁，下面是具体的实现：
public final boolean releaseShared(int releases) { if (tryReleaseShared(arg)) { doReleaseShared(); return true; } return false; }releases 是要释放的共享资源数量，其中 tryReleaseShared 的方法由我们自己重写，该方法的主要功能就是修改共享资源的数量（state + releases），因为可能会有多个线程同时释放资源，所以实现的时候，一般采用循环加 CAS 操作的方式，如下面的形式：
protected boolean tryReleaseShared(int releases) { // 释放共享资源，因为可能有多个线程同时执行，所以需要使用 CAS 操作来修改资源总数。 for (;;) { int lastCount = getState(); int newCount = lastCount + releases; if (compareAndSetState(lastCount, newCount)) { return true; } } }当共享资源数量修改了之后，会调用 doReleaseShared 方法，该方法主要唤醒同步队列中的第一个等待节点（head.next），下面是具体实现：
private void doReleaseShared() { /* * Ensure that a release propagates, even if there are other * in-progress acquires/releases. This proceeds in the usual * way of trying to unparkSuccessor of head if it needs * signal. But if it does not, status is set to PROPAGATE to * ensure that upon release, propagation continues. * Additionally, we must loop in case a new node is added * while we are doing this. Also, unlike other uses of * unparkSuccessor, we need to know if CAS to reset status * fails, if so rechecking. */ for (;;) { Node h = head; // head = null 说明没有初始化，head = tail 说明同步队列中没有等待节点 if (h != null && h != tail) { // 查看当前节点的等待状态 int ws = h.waitStatus; // 我们在前面说过，SIGNAL说明有后续节点需要唤醒 if (ws == Node.SIGNAL) { /* * 将当前节点的值设为 0，表明已经唤醒了后继节点 * 可能会有多个线程同时执行到这一步，所以使用 CAS 保证只有一个线程能修改成功， * 从而执行 unparkSuccessor，其他的线程会执行 continue 操作 */ if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0)) continue; // loop to recheck cases unparkSuccessor(h); } else if (ws == 0 && !compareAndSetWaitStatus(h, 0, Node.PROPAGATE)) { /* * ws 等于 0，说明无需唤醒后继结点（后续节点已经被唤醒或者当前节点没有被阻塞的后继结点）， * 也就是这一次的调用其实并没有执行唤醒后继结点的操作。就类似于我只需要一张优惠券， * 但是我的两个朋友，他们分别给我了一张，因此我就剩余了一张。然后我就将这张剩余的优惠券 * 送（传播）给其他人使用，因此这里将节点置为可传播的状态（PROPAGATE） */ continue; // loop on failed CAS } } if (h == head) // loop if head changed break; } }从上面的实现中，doReleaseShared 的主要作用是用来唤醒阻塞的节点并且一次只唤醒一个，让该节点关联的线程去重新竞争锁，它既不修改同步队列，也不修改共享资源。
当多个线程同时释放资源时，可以确保两件事：
1.共享资源的数量能正确的累加2.至少有一个线程被唤醒，其实只要确保有一个线程被唤醒就可以了，即便唤醒了多个线程，在同一时刻，也只能有一个线程能得到竞争锁的资格，在下面我们会看到。所以释放锁做的主要工作还是修改共享资源的数量。而有了多个共享资源后，如何确保同步队列中的多个节点可以获取锁，是由获取锁的逻辑完成的。下面看下共享锁的获取。
下面是获取共享锁的流程：
通过 acquireShared 方法，我们可以申请共享锁，下面是具体的实现：
public final void acquireShared(int arg) { // 如果返回结果小于 0，证明没有获取到共享资源 if (tryAcquireShared(arg) < 0) doAcquireShared(arg); }如果没有获取到共享资源，就会执行 doAcquireShared 方法，下面是该方法的具体实现：
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) { int r = tryAcquireShared(arg); if (r >= 0) { setHeadAndPropagate(node, r); p.next = null; // help GC if (interrupted) selfInterrupt(); failed = false; return; } } if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } }从上面的代码中可以看到，只有前置节点为 head 的节点才有可能去竞争锁，这点和独占模式的处理是一样的，所以即便唤醒了多个线程，也只有一个线程能进入竞争锁的逻辑，其余线程会再次进入 park 状态，当线程获取到共享锁之后，会执行 setHeadAndPropagate 方法，下面是具体的实现：
private void setHeadAndPropagate(Node node, long propagate) { // 备份一下头节点 Node h = head; // Record old head for check below /* * 移除头节点，并将当前节点置为头节点 * 当执行完这一步之后，其实队列的头节点已经发生改变， * 其他被唤醒的线程就有机会去获取锁，从而并发的执行该方法， * 所以上面备份头节点，以便下面的代码可以正确运行 */ setHead(node); /* * Try to signal next queued node if: * Propagation was indicated by caller, * or was recorded (as h.waitStatus either before * or after setHead) by a previous operation * (note: this uses sign-check of waitStatus because * PROPAGATE status may transition to SIGNAL.) * and * The next node is waiting in shared mode, * or we don't know, because it appears null * * The conservatism in both of these checks may cause * unnecessary wake-ups, but only when there are multiple * racing acquires/releases, so most need signals now or soon * anyway. */ /* * 判断是否需要唤醒后继结点，propagate > 0 说明共享资源有剩余， * h.waitStatus < 0，表明当前节点状态可能为 SIGNAL，CONDITION，PROPAGATE */ if (propagate > 0 || h == null || h.waitStatus < 0 || (h = head) == null || h.waitStatus < 0) { Node s = node.next; // 只有 s 不处于独占模式时，才去唤醒后继结点 if (s == null || s.isShared()) doReleaseShared(); } }判断后继结点是否需要唤醒的条件是十分宽松的，也就是一定包含必要的唤醒，但是也有可能会包含不必要的唤醒。从前面我们可以知道 doReleaseShared 函数的主要作用是唤醒后继结点，它既不修改共享资源，也不修改同步队列，所以即便有不必要的唤醒也是不影响程序正确性的。如果没有共享资源，节点会再次进入等待状态。
到了这里，脉络就比较清晰了，当一个节点获取到共享锁之后，它除了将自身设为 head 节点之外，还会判断一下是否满足唤醒后继结点的条件，如果满足，就唤醒后继结点，后继结点获取到锁之后，会重复这个过程，直到判断条件不成立。就类似于考试时从第一排往最后一排传卷子，第一排先留下一份，然后将剩余的传给后一排，后一排会重复这个过程。如果传到某一排卷子没了，那么位于这排的人就要等待，直到老师又给了他新的卷子。
在获取锁时还可以设置响应中断，独占锁和共享锁的处理逻辑类似，这里我们以独占锁为例。使用 acquireInterruptibly 方法，在获取独占锁时可以响应中断，下面是具体的实现：
public final void acquireInterruptibly(int arg) throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); if (!tryAcquire(arg)) doAcquireInterruptibly(arg); } private void doAcquireInterruptibly(int arg) throws InterruptedException { final Node node = addWaiter(Node.EXCLUSIVE); boolean failed = true; try { for (;;) { final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return; } if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) { // 这里会抛出异常 throw new InterruptedException(); } } } finally { if (failed) cancelAcquire(node); } }从上面的代码中我们可以看出，acquireInterruptibly 和 acquire 的逻辑类似，只是在下面的代码处有所不同：当线程因为中断而退出阻塞状态时，会直接抛出 InterruptedException 异常。
if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) { // 这里会抛出异常 throw new InterruptedException(); }我们知道，不管是抛出异常还是方法返回，程序都会执行 finally 代码，而 failed 肯定为 true，所以抛出异常之后会执行 cancelAcquire 方法，cancelAcquire 方法主要将节点从同步队列中移除。下面是具体的实现：
private void cancelAcquire(Node node) { // Ignore if node doesn't exist if (node == null) return; node.thread = null; // 跳过前面的已经取消的节点 Node pred = node.prev; while (pred.waitStatus > 0) node.prev = pred = pred.prev; // 保存下 pred 的后继结点，以便 CAS 操作使用 // 因为可能存在已经取消的节点，所以 pred.next 不一等于 node Node predNext = pred.next; // Can use unconditional write instead of CAS here. // After this atomic step, other Nodes can skip past us. // Before, we are free of interference from other threads. // 将节点状态设为 CANCELED node.waitStatus = Node.CANCELLED; // If we are the tail, remove ourselves. if (node == tail && compareAndSetTail(node, pred)) { compareAndSetNext(pred, predNext, null); } else { // If successor needs signal, try to set pred's next-link // so it will get one. Otherwise wake it up to propagate. int ws; if (pred != head && ((ws = pred.waitStatus) == Node.SIGNAL || (ws <= 0 && compareAndSetWaitStatus(pred, ws, Node.SIGNAL))) && pred.thread != null) { Node next = node.next; if (next != null && next.waitStatus <= 0) compareAndSetNext(pred, predNext, next); } else { unparkSuccessor(node); } node.next = node; // help GC } }从上面的代码可以看出，节点的删除分为三种情况：
删除节点为尾节点，直接将该节点的第一个有效前置节点置为尾节点删除节点的前置节点为头节点，则对该节点执行 unparkSuccessor 操作删除节点为中间节点，结果如下图所示。下图中（1）表示同步队列的初始状态，假设删除 node2， node1 是正常节点（非 CANCELED），（2）就是删除 node2 后同步队列的状态，此时 node1 节点的后继已经变为 node3，也就是说当 node1 变为 head 之后，会直接唤醒 node3。当另外的一个节点中断之后再次执行 cancelAcquire，在执行下面的代码时，会使同步队列的状态由（2）变为（3），此时 node2 已经没有外界指针了，可以被回收了。如果一直没有另外一个节点中断，也就是同步队列一直处于（2）状态，那么需要等 node3 被回收之后，node2 才可以被回收。 Node pred = node.prev; while (pred.waitStatus > 0) node.prev = pred = pred.prev;超时是在中断的基础上加了一层时间的判断，这里我们还是以独占锁为例。 tryAcquireNanos 支持获取锁的超时处理，下面是具体实现：
public final boolean tryAcquireNanos(int arg, long nanosTimeout) throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); return tryAcquire(arg) || doAcquireNanos(arg, nanosTimeout); }当获取锁失败之后，会执行 doAcquireNanos 方法，下面是具体实现：
private boolean doAcquireNanos(int arg, long nanosTimeout) throws InterruptedException { if (nanosTimeout <= 0 L) return false; // 线程最晚结束时间 final long deadline = System.nanoTime() + nanosTimeout; final Node node = addWaiter(Node.EXCLUSIVE); boolean failed = true; try { for (;;) { final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return true; } // 判断是否超时，如果超时就返回 nanosTimeout = deadline - System.nanoTime(); if (nanosTimeout <= 0 L) return false; // 这里如果设定了一个阈值，如果超时的时间比阈值小，就认为 // 当前线程没必要阻塞，再执行几次 for 循环估计就超时了 if (shouldParkAfterFailedAcquire(p, node) && nanosTimeout > spinForTimeoutThreshold) LockSupport.parkNanos(this, nanosTimeout); if (Thread.interrupted()) throw new InterruptedException(); } } finally { if (failed) cancelAcquire(node); } }当线程超时返回时，还是会执行 cancelAcquire 方法，cancelAcquire 的逻辑已经在前面说过了，这里不再赘述。
1.请问flag1和flag2是多少？
static AtomicStampedReference<Integer> atomicStampedR = new AtomicStampedReference<Integer>(100, time); boolean flag1 = atomicStampedR.compareAndSet(100, 200, time, time + 1); boolean flag2 = atomicStampedR.compareAndSet(200, 100, time, time + 1);flag1: true flag2: false
因为200的Integer 不等于 200的Integer Integer缓存的是-127 - 128，所以无法修改成功，虽然时间戳期望值是一样的
2.自己实现可重入的自旋锁，仅供参考
public class ReentrantSpinLock{ private AtomicReference<Thread> cas = new AtomicReference<Thread>(); private int count; public void lock(){ Thread current = Thread.currentThread(); if(current == cas.get()){ count++; return; } while(!cas.compareAndSet(null, current)){ } } public void unlock(){ Thread current = Thread.currentThread(); if(current == cas.get()){ if(count > 0) { count--; }else{ cas.compareAndSet(current, null); } } } }1.请自行阅读Lock、Condition原理，CountDownLatch、CyclicBarrier、Semaphore原理。
2.请根据同步器AQS实现自己的独占锁。
3.请说明ReentrantLock中公平锁与非公平锁是如何实现的？
