CountDownLatch
闭锁可以使一个或多个线程等待一组事件的发生，内部的计数器记录了事件的数量。两个主要的方法就是await和countDown。
public void await() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}
public void countDown() {
sync.releaseShared(1)
}
可以看到，这两种均使用了AQS中的共享类型方法。因此在同步器中他也需要实现tryAcquiredShared方法和tryReleaseShared方法。在tryAcquiredShared实现中，如果state=0则表示成功返回1(要等待的事件全部发生)，表示后续的acquire也会成功，否则返回-1表示acquire失败。在tryReleaseShared方法中，获取state并减1(发生了一个事件)，如果减到0则release成功。
然后我们描述一下await的整个过程。首先我们假设CountDownLatch的初始值为n。一个线程调用了await方法，此时同步器调用acquireSharedInterruptibly(1)。在这个方法中，首先会在共享模式下try一下，根据上一段我们的描述，此时state=n显然不为0，那么try失败，调用doAcquireSharedInterruptibly。在这个方法里，与其他acquire方法基本类似，都会在同步队列添加一个节点，然后判断前驱是否为head以决定能否立即try一次。如果前驱为head，并且try成功了需要调用setHeadAndPropagate(显然本次不会调用)。然后会把前驱设为SIGNAL并阻塞当前线程。
接下来是countDown过程，表示一个事件发生了。还是一样的首先都会try一下，获取state并减1，此时state=n-1.我们先假设state仍旧大于0即还有事件没有发生，那么tryReleaseShared会返回false。这种情况下releaseShared会直接返回！
那么当state=1的时候又调用了一次releaseShared会发生什么呢。同样的我们先try一下，这是经过CAS比较我们发现state=0了！然后我们就需要研究一下同步队列了，如果队列头结点是SIGNAL，就表明它的后继正等待被唤醒，然后我们就解锁其后继节点(只解锁了一个！)。这时，第一个进入同步队列的线程被唤醒，它将从被阻塞的地方继续执行，然后调用一次tryAcquireShared，此时会成功，因为state=0了。然后该节点将自己设置为队列头(setHeadAndPropagate)，并在该方法内调用了一次doReleaseShared，这将导致后续的节点被依次唤醒。
Semaphore
信号量中有两种模式，即公平和非公平模式。它用于实现控制同时访问某个资源的操作数量。唯一的区别就是在tryAcquire的时候，公平模式会先看一下所在同步队列前面有没有节点在等，如果有则标记自己本次try失败。
Semaphore的acquire操作会调用acquireSharedInterruptibly方法。此时如果资源数够，那么CAS设置state。如果资源不够，就需要进入同步队列等待了。其执行结构与CountDownLatch并无区别。但要注意的是这里的tryAcquire很好的反映了该方法的定义，如果返回值>0，表示后继的acquire可能会成功；如果返回值=0，那么本次成功，后继的acquire不成功；如果<0则失败。当资源值小于等于0的时候线程就会被park方法阻塞掉。
同样的release操作会将信号量state递增，并解锁一个后继节点。被唤醒的线程会继续尝试tryAcquire，如果递增后的信号量依旧小于0，那么继续阻塞。如果大于0，那么try成功，该节点将自己设为头结点并继续调用doReleaseShared()方法解锁后继节点。
通过这两种可以发现，利用同步器的工具类需要的就是根据自己的需求实现相关的acquire和release操作。在闭锁中，acquire成功与否取决于事件数是否为0，而在信号量中则取决于资源数是否大于0.同样，操作release，闭锁需要将事件数-1，而信号量需要将事件数+1.这两种同步工具类均使用了共享模式，因为可能允许多个线程同时获取锁。并且release导致的解锁只会解锁一个后继节点，后续节点的解锁操作将依靠前驱节点的传播过程。
