ReentrantReadWriteLock
概述
严格来说 ReentrantReadWriteLock 是锁，不应该在这篇文章里，但是为了篇幅，还是将它放入。 ReentrantReadWriteLock 实现 ReadWriteLock 接口：
public interface ReadWriteLock {
//获得读锁
Lock readLock();
//获得写锁
Lock writeLock();
}
其中写锁是独占锁，读锁是共享锁。
使用场景
一个资源能够被多个读线程访问，或者被一个写线程访问，但是不能同时存在读写线程。
适用于一个共享资源被大量读取操作，而只有少量的写操作（修改数据）。
特点
- 公平性: 读锁之间没有公平性，但是写锁是独占锁，它的公平性规则和 ReentrantLock 一样分为 公平锁 和 非公平锁（默认）；
- 重入性
- 读写锁允许读线程和写线程按照请求锁的顺序重新获取读取锁或者写入锁。当然只有写线程释放了锁，读线程才能重新获取重入锁；
- 写线程获取写入锁，可以再次获取读取锁，但是读线程获取读取锁后却不能获取写入锁
- 读写锁最多支持 65535 个重入的写入锁和读取锁。因为读写锁的同步器继承 AQS，AQS 的 state 用来表示重入的线程数，它的高 16 位用来表示写线程重入数，低 16 位 用来表示读线程重入数，所以最多支持 65535。
- 锁降级。写线程获取写入锁后可以获取读写锁，然后释放写入锁，这样就从写入锁变成了读取锁，实现锁降级；
- 不支持锁升级。
- 条件变量（Condition）
- 写入锁是独占锁。提供条件变量支持；
- 读取锁是共享锁，不允许获取条件变量，否则会抛出 UnsupportedOperationException
实例代码
class CachedData {
private Object data;
private volatile boolean cacheValid;
private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
public void processCachedData() {
rwl.readLock().lock();
if (!cacheValid) {
// Must release read lock before acquiring write lock
rwl.readLock().unlock();
rwl.writeLock().lock();
// Recheck state because another thread might have acquired
// write lock and changed state before we did.
if (!cacheValid) {
data = ...
cacheValid = true;
}
// Downgrade by acquiring read lock before releasing write lock
rwl.readLock().lock();
rwl.writeLock().unlock(); // Unlock write, still hold read
}
use(data);
rwl.readLock().unlock();
}
}
Semaphore
概述
Semaphore（信号量）用来控制同时访问某个特定资源的操作数量，或者同时执行某个指定操作的数量。常用来实现某种资源池，或者对容器施加边界。
Semaphore 管理者一组虚拟的许可（permit），许可的初始数量可以通过构造函数制定。具体应用中，执行操作之前首先获得许可，并在使用以后释放许可，如果许可不够，线程将被挂起。如果许可初始数量为 1，则 Semaphore 被称作计算信号量，可以用作互斥体（Mutex），并且拥有了不可重入的加锁语义。
Semaphore 内部的 Sync 继承自 AQS，使用了其共享模式的接口，所以 Semaphore 并不支持 Condition 条件变量。
实例代码
class BoundHashSet<T> {
private final Set<T> set;
private final Semaphore sem;
public BoundHashSet(int bound) {
set = new HashSet<T>();
sem = new Semaphore(bound);
}
public boolean add(T o) throws InterruptedException {
sem.acquire();
boolean wasAdded = false;
try {
wasAdded = set.add(o);
return wasAdded;
} finally {
if (!wasAdded) {
sem.release();
}
}
}
public boolean remove(T o) {
boolean wsRemoved = set.remove(o);
if (wsRemoved) {
sem.release();
}
return wsRemoved;
}
}
CountDownLatch
概述
CountDownLatch 是一种灵活的闭锁实现，闭锁 是一种同步工具，可以延迟线程的进度直到其到达终止状态。它的作用相当于一扇门：在闭锁到达结束状态之前，这扇门一直关闭，没有任何线程通过，当到达结束状态时，这扇门会打开允许所有线程通过。
使用场景
闭锁（CountDownLatch）可以用来确保某些活动直到其他活动都完成了才继续执行。比如：
- 确保某个计算在其需要的所有资源都被初始化之后才继续执行；
- 确保某个服务在其依赖的所有其他服务都已经启动后才启动；
- 等待知道某个操作的所有参与者都就绪再继续执行。
主要接口
CountDownLatch 有两类主要接口：
//供等待线程调用
public void await() throws InterruptedException
public boolean await(long timeout, TimeUnit unit)
throws InterruptedException
//共通知线程调用
public void countDown()
CountDownLatch 内部的 Sync 继承自 AQS，私用的 state 代等待线程的计数器 count。调用CountDownLatch.await 的线程会阻塞挂起，一直到计数器减到 0。其他线程调用 CountDownLatch.countDown，每次都会递减计数器，计时器到 0 时，会唤醒所有阻塞在 await 的线程。他们的调用时序图如下所示：
特点
CountDownLatch 注意以下特点：
- 等待计数器 count 只有 CountDownLatch 初始化时才能设置，没有其他接受改变它，所以 CountDownLatch 是一次性的同步类；
- 调用 await 和 countDown 的线程不可能是同一个；
- 内部 Sync 重载的是 AQS 共享模式接口，所以不支持 Condition。
编程实践
// 一个CountDownLatch实例是不能重复使用的，也就是说它是一次性的，锁一经被打开就不能再关闭使用了，如果想重复使用，请考虑使用CyclicBarrier。
public class CountDownLatchTest {
// 模拟了100米赛跑，10名选手已经准备就绪，只等裁判一声令下。当所有人都到达终点时，比赛结束。
public static void main(String[] args) throws InterruptedException {
// 开始的倒数锁
final CountDownLatch begin = new CountDownLatch(1);
// 结束的倒数锁
final CountDownLatch end = new CountDownLatch(10);
// 十名选手
final ExecutorService exec = Executors.newFixedThreadPool(10);
for (int index = 0; index < 10; index++) {
final int NO = index + 1;
Runnable run = new Runnable() {
public void run() {
try {
// 如果当前计数为零，则此方法立即返回。
// 等待
begin.await();
Thread.sleep((long) (Math.random() * 10000));
System.out.println("No." + NO + " arrived");
} catch (InterruptedException e) {
} finally {
// 每个选手到达终点时，end就减一
end.countDown();
}
}
};
exec.submit(run);
}
System.out.println("Game Start");
// begin减一，开始游戏
begin.countDown();
// 等待end变为0，即所有选手到达终点
end.await();
System.out.println("Game Over");
exec.shutdown();
}
}
CyclicBarrier
概述
CyclicBarrier 的字面意思是可循环使用（Cyclic）的栅栏（Barrier）。栅栏类似于闭锁，它能阻塞一组线程直到某个事件发生。栅栏和闭锁的关键区别在于，所有线程必须都到达栅栏位置，才能继续执行。闭锁用于等待事件，栅栏用于等待线程。
使用场景
CyclicBarrier 在并行迭代算法中非常有用，这种算法通常将一个问题拆分成一系列相互独立的子问题，各个子问题由不同线程计算，单个线程计算完成后调用 await 等候在栅栏处，所有线程计算完毕后都等候在栅栏时，栅栏再打开释放所有线程。
如果某个线程的 await 超时或者被中断，其他已经在 await 的线程会终止等待并抛出 BrokenBarrierException。
特点
- 可以循环使用，栅栏释放所有线程后，重新初始化 count 计数器。
- 提供 reset 接口重置 count 计数器，已经 await 的线程会抛出 BrokenBarrierException。
- 初始化时可以传入 Runnable 接口的实现，所有线程都到达栅栏后，在最后一个到达线程上执行这个 Runnable。
- 内部使用 ReentrantLock 和 Condition 控制同步，而不是用继承 AQS 的 Sync。
编程实践
class CyclicBarrierTest {
static CyclicBarrier c = new CyclicBarrier(2);
public static void main(String[] args) {
new Thread(new Runnable() {
@Override
public void run() {
try {
c.await();
} catch (Exception e) {}
System.out.println(1);
}
}).start();
try {
c.await();
} catch (Exception e) {}
System.out.println(2);
}
}
内容来源
Java 并行编程实战
https://my.oschina.net/adan1/blog/158107
http://www.cnblogs.com/liuling/archive/2013/08/21/2013-8-21-03.html
http://ifeve.com/concurrency-semaphore/
http://blog.csdn.net/lipeng_bigdata/article/details/52165426
http://www.itzhai.com/the-introduction-and-use-of-a-countdownlatch.html#read-more
http://developer.51cto.com/art/201403/432095.htm
http://www.importnew.com/15731.html
http://ifeve.com/concurrency-cyclicbarrier/
http://www.itzhai.com/the-introduction-and-use-of-cyclicbarrier.html#read-more
