Java并发基础之AbstractQueuedSynchronizer(AQS)

　　AbstractQueuedSynchronizer同步器是实现JUC核心基础组件，因为 定义了一套多线程访问共享资源的同步器框架。前面几篇文章中JUC同步工具中都利用AQS构建自身的阻塞类。AQS解决了子类实现同步器时涉及的大量细节问题，例如获取同步状态、FIFO同步队列等；同时采用模板方法模式，AQS实现大量通用方法，子类通过继承方式实现其抽象方法来管理同步状态。先看看其UML图：

　　　　　

　　首先从类名看这是一个抽象队列同步器，那么是这样的队列呢？CLH同步队列。

　　　　　

　　AQS它维护了一个 volatile int state（代表共享资源）和一个 FIFO 线程等待队列（多线程争用资源被阻塞时会进入此队列）。

　　通过AQS UML图可知state有三种访问方式：

　　　　

　　线程等待队列节点详细结构源码如下：

　　　　

　　其中acquire/release、acquireShared/releaseShared 是AQS里面的两对模板方法。以acquire为例跟踪分析具体方法：

　　　　

　　获取操作可能是独占的exclusive(ReentrantLock)，也可能是非独占的share(Semaphore和CountDownLatch)，取决于不同的Synchronizer。

　　　　

　　AQS 只是一个框架，具体资源的获取/释放方式交由自定义同步器去实现， AQS 这里只定义了一个接口，具体资源的获取交由自定义同步器去实现了（通过 state 的 get/set/CAS)之所以没有定义成abstract ，是 因 为独 占模 式 下 只 用实现 tryAcquire-tryRelease ，而 共享 模 式 下 只用 实 现tryAcquireShared-tryReleaseShared。如果都定义成abstract，那么每个模式也要去实现另一模式下的接口。不同的自定义同步器争用共享资源的方式也不同。自定义同步器在实现时只需要实现共享资源 state 的获取与释放方式即可，至于具体线程等待队列的维护（如获取资源失败入队/唤醒出队等）， AQS 已经在顶层实现好了。自定义同步器实现时主要实现以下几种方法：　　　　　　　　

　　　　1． isHeldExclusively()：该线程是否正在独占资源。只有用到 condition 才需要去实现它。

　　　　2． tryAcquire(int)：独占方式。尝试获取资源，成功则返回 true，失败则返回 false。

　　　　3． tryRelease(int)：独占方式。尝试释放资源，成功则返回 true，失败则返回 false。

　　　　4． tryAcquireShared(int)：共享方式。尝试获取资源。负数表示失败； 0 表示成功，但没有剩余可用资源；正数表示成功，且有剩余资源。

　　　　5． tryReleaseShared(int)：共享方式。尝试释放资源，如果释放后允许唤醒后续等待结点返回true，否则返回 false。

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

　　一个获取操作分为两步：

　　　　第一步，Synchronizer判断当期状态是否允许被获得。如果是，就让线程执行；如果不是，获取操作阻塞或者失败。具体判断有Synchronizer的语意决定，可以举例说明：如果想成功获取锁，锁必须是未被占有的；二如果想成功地获取闭锁，闭锁必须未处于终止状态。

　　　　第二步包括了可能需要更新的状态。一个想获取Synchronizer的线程会影响到其他线程是否能够获取它。例如，获取锁的操作将锁的状态从“未被占有”改变为“已被占有”；从Semaphore中获取许可的操作会检索剩余许可的数量。另一方面，一个响应对闭锁的请求操作却不会影响到其他薪酬是否能够获取他，所以获取闭锁的操作不会改变闭锁的状态。

　　除以上提到的tryXXX方法需要在子类中重写，其他AQS提供的模板方法可参考显式锁之ReentrantLock实现 - 池塘里洗澡的鸭子 - 博客园 (cnblogs.com)及相关利用AQS实现的阻塞类的使用。