1. 在线程中执行任务
1.1 串行的执行任务
这是最经典的一个最简单的Socket server的例子，服务器的资源利用率非常低，因为单线程在等待I/O操作完成时，CPU处于空闲状态。从而阻塞了当前请求的延迟，还彻底阻止了其他等待中的请求被处理。
public class SingleThreadWebServer {
public static void main(String[] args) throws IOException {
ServerSocket socket = new ServerSocket(80);
while (true) {
Socket connection = socket.accept();
handleRequest(connection);
}
}
private static void handleRequest(Socket connection) {
// request-handling logic here
}
}
1.2 显式地为任务创建线程
任务处理从主线程中分离出来，主循环可以快速等待下一个连接，提高响应性。同时任务可以并行处理了，吞吐量也提高了。
public class ThreadPerTaskWebServer {
public static void main(String[] args) throws IOException {
ServerSocket socket = new ServerSocket(80);
while (true) {
final Socket connection = socket.accept();
Runnable task = new Runnable() {
public void run() {
handleRequest(connection);
}
};
new Thread(task).start();
}
}
private static void handleRequest(Socket connection) {
// request-handling logic here
}
}
1.3 无限制创建线程的不足
- 线程的生命周期开销非常高
- 资源消耗。大量的空闲线程占用内存，给GC带来压力，同时线程数量过多，竞争CPU资源开销太大。
稳定性。容易引起GC问题，甚至OOM
2 Executor框架
任务就是一组逻辑工作单元（unit of work），而线程则是使任务异步执行的机制。
Executor接口，是代替Thread来做异步执行的入口，接口虽然简单，却为非常灵活强大的异步任务执行框架提供了基础。
提供了一种标准的方法将任务的提交与执行过程解耦，并用Runnable（无返回时）或者Callable（有返回值）表示任务。
Executor基于生产者-消费者模式
提交任务/执行任务分别相当于生产者/消费者,通常是最简单的实现生产者-消费者设计的方式了
2.1 基于Executor改造后的样例如下
将请求处理任务的提交与任务的实际执行解耦,并且只需采用另一种不同的Executor实现,就可以改变服务器的行为,其影响远远小于修改任务提交方式带来的影响
2.2 执行策略
这一节主要介绍做一个Executor框架需要靠那些点？
在什么线程中执行任务？
任务按照什么顺序执行？FIFO/LIFO/优先级
有多少个任务可以并发执行？
队列中允许多少个任务等待？
如果系统过载了要拒绝一个任务，那么选择拒绝哪一个？如何通知客户端任务被拒绝了？
在执行任务过程中能不能有些别的动作before/after或者回调？
各种执行策略都是一种资源管理工具，最佳的策略取决于可用的计算资源以及对服务质量的要求。
因此每当看到
new Thread(runnable).start();
并且希望有一种灵活的执行策略的时候，请考虑使用Executor来代替
2.3 线程池
在线程池中执行任务比为每个任务分配一个线程优势明显：
重用线程，减少开销。
延迟低，线程是等待任务到达。
最大化挖掘系统资源以及保证稳定性。CPU忙碌但是又不会出现线程竞争资源而耗尽内存或者失败的情况。
Executors可以看做一个工厂，提供如下几种Executor的创建：
newCachedThreadPool
newFixedThreadPool
newSingleThreadExecutor
newScheduledThreadPool
2.4 Executor的生命周期
为解决执行服务的生命周期问题,Executor扩展了ExecutorService接口,添加了一些用于生命周期管理的方法
一个优雅停止的例子：
增加生命周期扩展Web服务器的功能
关闭
2.5 延迟任务与周期任务
使用Timer的弊端在于
- 如果某个任务执行时间过长，那么将破坏其他TimerTask的定时精确性(执行所有定时任务时只会创建一个线程),只支持基于绝对时间的调度机制,所以对系统时钟变化敏感
- TimerTask抛出未检查异常后就会终止定时线程(不会捕获异常)
更加合理的做法是使用ScheduledThreadPoolExecutor,只支持基于相对时间的调度
它是DelayQueue的应用场景
3 找出可利用的并行性
3.1 携带结果的任务Callable和Future
Executor框架支持Runnable，同时也支持Callable(它将返回一个值或者抛出一个异常)
在Executor框架中，已提交但是尚未开始的任务可以取消，但是对于那些已经开始执行的任务，只有他们能响应中断时，才能取消。
Future非常实用，他的API如下
内部get的阻塞是靠LockSupport.park来做的，在任务完成后Executor回调finishCompletion方法会依次唤醒被阻塞的线程。
ExecutorService的submit方法接受Runnable和Callable，返回一个Future。ThreadPoolExecutor框架留了一个口子，子类可以重写newTaskFor来决定创建什么Future的实现，默认是FutureTask类。
3.2 示例：使用Future实现页面的渲染器
3.3 CompletionService: Executor与BlockingQueue
计算完成后FutureTask会调用done方法，而CompletionService集成了FutureTask，对于计算完毕的结果直接放在自己维护的BlockingQueue里面，这样上层调用者就可以一个个take或者poll出来。
3.3 示例：使用CompletionService提高渲染性能
void renderPage(CharSequence source) {
final List<ImageInfo> info = scanForImageInfo(source);
CompletionService<ImageData> completionService =
new ExecutorCompletionService<ImageData>(executor);
for (final ImageInfo imageInfo : info)
completionService.submit(new Callable<ImageData>() {
public ImageData call() {
return imageInfo.downloadImage();
}
});
renderText(source);
try {
for (int t = 0, n = info.size(); t < n; t++) {
Future<ImageData> f = completionService.take();
ImageData imageData = f.get();
renderImage(imageData);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} catch (ExecutionException e) {
throw launderThrowable(e.getCause());
}
}
6.3.7 为任务设置时限
Future的get支持timeout。
6.3.8 批量提交任务
使用invokeAll方法提交List<Callable>，返回一个List<Future>
