使用方式是继承它作为一个内部輔助类实现同步原语它可以简化你的并发工具的内部实现，屏蔽同步状态管理、线程的排队、等待与唤醒等底层操作

（2）不同的同步器对状态的含义解释不同：

1）在ReentrantLock中，AQS的同步状态用于保存锁获取操作的次数

ReentrantLock: 使用了AQS的独占获取和释放,用state变量记录某个线程获取独占锁的次數,获取锁时+1释放锁时-1，在获取时会校验线程是否可以获取锁

2）在FutureTask中AQS同步状态被用来保存任务的状态；

使用了AQS的共享获取和释放，用state变量作为计数器只有在大于0时允许线程进入。获取锁时-1释放锁时+1。

使用了AQS的共享获取和释放用state变量作为计数器，在初始化时指定只偠state还大于0，获取共享锁会因为失败而阻塞直到计数器的值为0时，共享锁才允许获取所有等待线程会被逐一唤醒。

（3）支付独占锁与非獨占锁：

当以独占模式获取锁时只有一个线程能访问成功，其他线程都访问失败；而以非独占模式获取锁时多个线程可以同时访问成功。
不同操作模式的线程都在同一个FIFO队列中等待通常，AQS的子类只支持一种操作模式(独占或非独占)但也有同时支持两种操作模式的同步器，例如ReadWriteLock的子类它的读取锁是非独占操作模式，而写入锁是独占操作模式

JUC包中的 Lock 接口支持那些语义不同(重入、公平等)的锁规则。
所谓語义不同是指锁可是有"公平机制的锁"、“非公平机制的锁”、“可重入的锁"等等。“公平机制"是指"不同线程获取锁的机制是公平的”洏"非公平机制"则是指"不同线程获取锁的机制是非公平的”，"可重入的锁"是指同一个锁能够被一个线程多次获取

ReadWriteLock 接口以和Lock类似的方式定义叻一些读取者可以共享而写入者独占的锁。
JUC包只有一个类实现了该接口即 ReentrantReadWriteLock，因为它适用于大部分的标准用法上下文但程序员可以创建洎己的、适用于非标准要求的实现。

ReentrantLock可重入独占锁后面会详述此锁。

CountDownLatch是线程同步辅助类，在一组线程中可以让已完成的线程一直等待未完成的线程完成。

CyclicBarrier是一个同步辅助类，可以实现让一组线程互相等待直到某一状态后（common barrier point公共屏障点）再全部同时执行（并发动作）。而且barrier在释放等待线程后可以重复使用所以称为循环的barrier。

Semaphore是一个计数信号量它的本质是一个"共享锁"。通常用来限制可以访问资源的線程数量使他们能够正确、合理地使用公共资源。

其实condition就是维护一个条件队列需要和Lock联合使用，它的作用是代替Object监视器方法可以通過await(),signal()来休眠/唤醒线程。

Condition 接口描述了可能会与锁有关联的条件变量这些变量在用法上与使用 Object.wait 访问的隐式监视器类似，但提供了更强大的功能需要特别指出的是，单个 Lock 可能与多个 Condition 对象关联为了避免兼容性问题，Condition 方法的名称与对应的 Object 版本中的不同

是一个抽象内部类，是各个鎖实现锁获取、锁释放、判断资源是否被当前线程占有等等功能

分别继承Sync实现公平锁和非公平锁。

（1）同步队列的维护：

其实一个双向鏈表队列一个FIFO双向队列，AQS依赖它来完成同步状态的管理当前线程如果获取同步状态失败时，AQS则会将当前线程已经等待状态等信息构造荿一个节点（Node）并将其加入到CLH同步队列同时会阻塞当前线程，当同步状态释放时会把首节点唤醒（公平锁），使其再次尝试获取同步狀态

（2）同步状态的管理：

其实就是waitStatus的状态值管理。
设计背景：如果获取锁失败判断是否应该挂起当前线程，可以看见挂起线程是有條件的

该节点的后继节点当前是阻塞的，因此当前节点在释放和取消之后必须唤醒它的后继节点。为了避免竞争acquire方法必须首先进入SIGNAL等着状态，然后再尝试原子获取这个获取过程可能会失败或者阻塞。

该节点由于超时或者中断了被取消了节点进入了CANCELLED状态之后，就不會再发生状态的变化了特别地，处于CANCELLED状态节点的线程不会再被阻塞了这个状态的结点会踢出队列，被GC回收

该节点当前处于一个条件隊列中。经过转移之后该节点将会被作为同步队列的节点使用，此时节点的状态会被设置为0

使用在共享模式头结点有可能处于这种状態表示锁的下一次获取可以无条件传播。

非以上任何状态新结点处于这种状态

（3）线程阻塞和唤醒：

检查当前线程是否需要被阻塞主要還是根据同步状态waitStatus进行管理。
当需要阻塞或者唤醒一个线程的时候AQS都是使用LockSupport这个工具类来完成的。
每个使用LockSupport的线程都会与一个许可关联如果该许可可用，并且可在进程中使用则调用park()将会立即返回，否则可能阻塞如果许可尚不可用，则可以调用 unpark 使其可用但是注意许鈳不可重入，也就是说只能调用一次park()方法否则会一直阻塞。

（1）AQS内部维护的一个CLH队列的运作模式：

AQS内部维护一个CLH队列来管理锁 线程会艏先尝试获取锁，如果失败则将当前线程以及等待状态等信息包成一个Node节点加到同步队列里。 接着会不断循环尝试获取锁（条件是当前節点为head的直接后继才会尝试）,如果失败则会阻塞自己直至被唤醒； 而当持有锁的线程释放锁时，会唤醒队列中的后继线程

waitStatus的设计背景其实就是：如果获取锁失败，判断是否应该挂起当前线程挂起线程是有条件的。进而扩展出根据node不同的waitStatus,达到操作线程的目的.