接上一篇
java并发包小结（一）：http://blog.csdn.net/aalansehaiyang52/article/details/8877579
Future 接口
Future 接口允许表示已经完成的任务、正在执行过程中的任务或者尚未开始执行的任务。通过 Future 接口，可以尝试取消尚未完成的任务，查询任务已经完成还是取消了，以及提取（或等待）任务的结果值。
FutureTask 类实现了 Future，并包含一些构造函数，允许将 Runnable 或 Callable（会产生结果的 Runnable）和 Future 接口封装。因为 FutureTask 也实现 Runnable，所以可以只将 FutureTask 提供给 Executor。一些提交方法（如 ExecutorService.submit()）除了提交任务之外，还将返回 Future 接口。
Future.get() 方法获取任务计算的结果（或如果任务完成，但有异常，则抛出 ExecutionException）。如果任务尚未完成，那么 Future.get() 将被阻塞，直到任务完成；如果任务已经完成，那么它将立即返回结果。
使用 Future 构建缓存
该示例代码与 java.util.concurrent 中的多个类关联，突出显示了 Future 的功能。它实现缓存，使用 Future 描述缓存值，该值可能已经计算，或者可能在其他线程中'正在构造'。
它利用 ConcurrentHashMap 中的原子 putIfAbsent() 方法，确保仅有一个线程试图计算给定关键字的值。如果其他线程随后请求同一关键字的值，它仅能等待（通过 Future.get() 的帮助）第一个线程完成。因此两个线程不会计算相同的值。
public class Cache {
ConcurrentMap map = new ConcurrentHashMap();
Executor executor = Executors.newFixedThreadPool(8);
public V get(final K key) {
FutureTask f = map.get(key);
if (f == null) {
Callable c = new Callable() {
public V call() {
// return value associated with key
}
};
f = new FutureTask(c);
FutureTask old = map.putIfAbsent(key, f);
if (old == null)
executor.execute(f);
else
f = old;
}
return f.get();
}
}
Semaphore
Semaphore 类实现标准 Dijkstra 计数信号。计数信号可以认为具有一定数量的许可权，该许可权可以获得或释放。如果有剩余的许可权，acquire() 方法将成功，否则该方法将被阻塞，直到有可用的许可权（通过其他线程释放许可权）。线程一次可以获得多个许可权。
注意信号不跟踪哪个线程拥有多少许可权；这由应用程序来决定，以确保何时线程释放许可权，该信号表示其他线程拥有许可权或者正在释放许可权，以及其他线程知道它的许可权已释放。
CountdownLatch
CountdownLatch 类与 CyclicBarrier 相似，因为它的角色是对已经在它们中间分摊了问题的一组线程进行协调。它也是使用整型变量构造的，指明计数的初始值，但是与 CyclicBarrier 不同的是，CountdownLatch 不能重新使用。
其中，CyclicBarrier 是到达屏障的所有线程的大门，只有当所有线程都已经到达屏障或屏障被打破时，才允许这些线程通过，CountdownLatch 将到达和等待功能分离。任何线程都可以通过调用 countDown() 减少当前计数，这种不会阻塞线程，而只是减少计数。await() 方法的行为与 CyclicBarrier.await() 稍微有所不同，调用 await() 任何线程都会被阻塞，直到闩锁计数减少为零，在该点等待的所有线程才被释放，对 await() 的后续调用将立即返回。
当问题已经分解为许多部分，每个线程都被分配一部分计算时，CountdownLatch非常有用。在工作线程结束时，它们将减少计数，协调线程可以在闩锁处等待当前这一批计算结束，然后继续移至下一批计算。
相反地，具有计数 1 的 CountdownLatch 类可以用作'启动大门'，来立即启动一组线程；工作线程可以在闩锁处等待，协调线程减少计数，从而立即释放所有工作线程。下例使用两个 CountdownLatche。一个作为启动大门，一个在所有工作线程结束时释放线程：
class Driver { // ...
void main() throws InterruptedException {
CountDownLatch startSignal = new CountDownLatch(1);
CountDownLatch doneSignal = new CountDownLatch(N);
for (int i = 0; i < N; ++i) // create and start threads
new Thread(new Worker(startSignal, doneSignal)).start();
doSomethingElse(); // don't let them run yet
startSignal.countDown(); // let all threads proceed
doSomethingElse();
doneSignal.await(); // wait for all to finish
}
}
class Worker implements Runnable {
private final CountDownLatch startSignal;
private final CountDownLatch doneSignal;
Worker(CountDownLatch startSignal, CountDownLatch doneSignal) {
this.startSignal = startSignal;
this.doneSignal = doneSignal;
}
public void run() {
try {
startSignal.await();
doWork();
doneSignal.countDown();
} catch (InterruptedException ex) {} // return;
}
}
Hashtable 与 ConcurrentHashMap
作为可伸缩性的例子，ConcurrentHashMap 实现设计的可伸缩性要比其线程安全的上一代 Hashtable 的可伸缩性强得多。Hashtable 一次只允许一个线程访问 Map；ConcurrentHashMap 允许多个读者并发执行，读者与写入者并发执行，以及一些写入者并发执行。因此，如果许多线程频繁访问共享映射，使用 ConcurrentHashMap 的总的吞吐量要比使用 Hashtable 的好。
下表大致说明了 Hashtable 和 ConcurrentHashMap 之间的可伸缩性差别。在每次运行时，N 个线程并发执行紧密循环，它们从 Hashtable 或 ConcurrentHashMap 中检索随即关键字，60% 的失败检索将执行 put() 操作，2% 的成功检索执行 remove() 操作。测试在运行 Linux 的双处理器 Xeon 系统中执行。数据显示 10,000,000 个迭代的运行时间，对于 ConcurrentHashMap，标准化为一个线程的情况。可以看到直到许多线程，ConcurrentHashMap 的性能仍保持可伸缩性，而 Hashtable 的性能在出现锁定竞争时几乎立即下降。
与通常的服务器应用程序相比，这个测试中的线程数看起来很少。然而，因为每个线程未进行其他操作，仅是重复地选择使用该表，所以这样可以模拟在执行一些实际工作的情况下使用该表的大量线程的竞争。
| 线程 | ConcurrentHashMap | Hashtable |
| 1 | 1.0 | 1.51 |
| 2 | 1.44 | 17.09 |
| 4 | 1.83 | 29.9 |
| 8 | 4.06 | 54.06 |
| 16 | 7.5 | 119.44 |
| 32 | 15.32 | 237.2 |