学习了AbstractQueuedSynchronizer 之后(Condition没有在上文做笔记，当应该不难理解)，接下来笔者就尝试着分析在JUC包中的各个同步器，其语义是如何实现的。

ReentrantLock

内部类Sync继承了AbstractQueuedSynchronizer。state表示锁被重入的次数。因为其是独占锁，所以只实现了tryRelease，isHeldExclusively方法，而tryAcquire则交由子类基于公平和非公平的策略来实现。

公平的ReentrantLock会在每次tryAcquire的时候，都老老实实让排在队列前面的线程优先拿锁。而非公平锁则是发现state为0后，就马上去尝试设置state，如果不能成功，才进入AQS内部的队列老老实实的排队。

ReentrantReadWriteLock

此类最为复杂。内部类Sync继承了AbstractQueuedSynchronizer，同时内部类ReadLock和WriteLock内部共享了Sync，state这个int被划分成两部分，高位16个bit表示共享读锁，低位16个bit表示独占写锁。

大概的工作方式是：读锁使用shared模式，复写tryAcquireShared和tryReleaseShared；写锁使用独占锁，复写tryAcquire和tryRelease。当线程要求锁住写锁的时候，内部会检查state是否为0；如果不为0，则检查此时是写状态还是读状态；如果是写状态，则检查持有写锁的是否是自己；如果是的话，则进行锁重入。锁住读锁也是这个道理，只不过是使用的shared的锁模式而已。

Semaphore

使用state表示信号量。可以想象，使用是的shared模式。在acquire的时候，会去比较state来判断是否可以成功。

需要注意的是此类如果使用不当，则可能会有线程被挂住的问题，测试代码可以参见这里：https://gist.github.com/3879133。

CountDownLatch

与Semaphore一样，都是非常简单的使用了state。

CyclicBarrier

内部使用的是ReentrantLock，利用了Condition来唤醒栅栏前的线程。

FutureTask

使用state来表示任务的执行状态。代码也相对比较简单。值得注意的是，FutureTask对于任务执行抛出的异常，是会捕捉住的（在get的时候才会给抛给你），如果在编写任务时候没有catch(Exception)，而导致有异常漏过业务代码，则很有可能产生不可预知的问题。比如，在使用 ScheduledExecutorService分发定时任务之后，而又不关心返回结果的时候，就可能会出现问题。所以一般对自己的线程，也应该处理自己线程的异常，这也是最佳实践的原则。

原文在我的博客上：http://www.zavakid.com/207