这篇笔记是关于 Doug Lea 的 The java.util.concurrent Synchronizer Framework 。
原文地址：http://gee.cs.oswego.edu/dl/papers/aqs.pdf。
1. JDK 1.5 引入 java.util.concurrent package（JSR 166）。
这个 package 包含了一些中级的并发支持类。
在这些类中有一个同步器（synchronizers）集合。这些同步器都维护了：
（1）一个内部的同步状态（synchronization state），用于表示一个锁是否已经上锁了；
（2）一些用于更新或检查这个同步状态的方法；
（3）至少有一个方法用于阻塞调用线程，在允许的条件下重新运行这个调用线程。
一些例子有：各种形式的互斥锁，读写锁，信号量，barrier，fututures， event indicators, handoff queues。
2. 基本上任一同步器都可以去实现其他同步器。
但这样做会带来额外的复杂度、开销和死板。另外，概念上讲也不吸引人。
JSR 166 建立了一个框架，以 AbstractQueuedSynchronizer 为核心，提供了一些通用的机制供大部分同步器使用。
3. 同步器拥有两类方法：acquire、release。
acquire: 阻塞调用线程直到同步状态允许它运行。
release:改变同步状态，唤醒一个或多个阻塞线程。
4. java.util.concurrent 包没有定义统一的同步器API。
不同的类中 acquire 和 release 有不同的名字和形式。
比如：Lock.lock, Semaphore.acquire, CountDownLatch.await, FutureTask.get 都对应于 acquire。
但是维护了一致的规约用于支持一系列通用的使用选项。
每个同步器都支持（有意义的情况下）：
(1) 非阻塞同步（tryLock）；
(2) 超时；
(3) 可中断；
5. 定义了一个Condition，支持monitor-style await/signal操作。
需要和Lock类一起使用。
6. 性能目标
Java内置锁（monitor lock）的性能一直是个关注点。
主要考虑优化空间和时间开销（这篇paper考虑的是JDK1.5； JDK1.6发布后，synchronized和ReentrantLock性能基本持平，参见周志明的《深入理解Java虚拟机》第二版，p392-p393。所以提倡在未来的JDK版本中，优先考虑使用synchronized来实现同步）。
java.util.concurrent优化的首要目标是scalability：在同步器竞争下可预期的维持效率。