The java.util.concurrent Synchronizer Framework笔记

这篇笔记是关于 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：在同步器竞争下可预期的维持效率。