同步器的核心方法是 release操作是这样的： 从这两个操作中的思想中我们可以提取出三大关键操作：同步器的状态变更、线程阻塞和释放、插入和移出队列。所以为了实现这两个操作，需要协调三大关键操作引申出来的三个基本组件： 由这三个基本组件，我们来看j.u.c是怎么设计的。 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只有一个同步队列，但是可以有多个条件队列。AQS框架提供了一个ConditionObject类，给维护独占同步的类以及实现Lock接口的类使用。 ConditionObject类实现了Condition接口，Condition接口提供了类似Object管程式的方法，如await、signal和signalAll操作，还扩展了带有超时、检测和监控的方法。ConditionObject类有效地将条件与其它同步操作结合到了一起。该类只支持Java风格的管程访问规则，这些规则中，当且仅当当前线程持有锁且要操作的条件（condition）属于该锁时，条件操作才是合法的。这样，一个ConditionObject关联到一个ReentrantLock上就表现的跟内置的管程（通过Object.wait等）一样了。两者的不同仅仅在于方法的名称、额外的功能以及用户可以为每个锁声明多个条件。 ConditionObject类和AQS共用了内部节点，有自己单独的条件队列。signal操作是通过将节点从条件队列转移到同步队列中来实现的，没有必要在需要唤醒的线程重新获取到锁之前将其唤醒。signal操作大致示意图如下： await操作就是当前线程节点从同步队列进入条件队列进行等待，大致示意图如下： 实现这些操作主要复杂在，因超时或Thread.interrupt导致取消了条件等待时，该如何处理。await和signal几乎同时发生就会有竞态问题，最终的结果遵照内置管程相关的规范。JSR133修订以后，就要求如果中断发生在signal操作之前，await方法必须在重新获取到锁后，抛出InterruptedException。但是，如果中断发生在signal后，await必须返回且不抛异常，同时设置线程的中断状态。 https://www.cnblogs.com/iou123lg/p/9464385.html设计思想
acquire和release操作，其背后的思想也比较简洁明确。acquire操作是这样的： while (当前同步器的状态不允许获取操作) {
如果当前线程不在队列中，则将其插入队列
阻塞当前线程
}
如果线程位于队列中，则将其移出队列
更新同步器的状态
if (新的状态允许某个被阻塞的线程获取成功){
解除队列中一个或多个线程的阻塞状态
}
同步状态
阻塞
队列
条件队列
原文