Executor与Task的耦合性
1，除非线程池很非常大，否则一个Task不要依赖同一个线程服务中的另外一个Task，因为这样容易造成死锁；
2，线程的执行是并行的，所以在设计Task的时候要考虑到线程安全问题。如果你认为只会在单任务线程的Executor中运行的话，从设计上讲这就已经耦合了。
3，长时间的任务有可能会影响到其他任务的执行效率，可以让其他线程在等待的时候限定一下等待时间。不要无限制地等待下去。
确定线程池的大小
给出如下定义：
要使CPU达到期望的使用率，线程池的大小应设置为：
约等于Ncpu+1。
定制线程池
通过Executor来创建的线程池其实是预先给我们打造好的线程池，例如：
如果不能满足需求，可以自己量身定做：
public ThreadPoolExecutor(int corePoolSize, //基本大小，没有执行任务时线程池的大小 int maximumPoolSize, //最大任务数量 long keepAliveTime, //最大空闲时间，超时后会被回收 TimeUnit unit, BlockingQueue<Runnable> workQueue) { //... }
任务队列：缓存任务
前面有说到，使用线程池的好处是可以限制线程的数量，因此保证服务器不会被超量的线程给拖垮。当并发请求增加，我们不再是盲目地创建线程了。而是简单地创建一个任务缓存到处理队列中了。那么问题来了，当并发请求继续激增，服务线程无法消化任务，造成大量的任务堆积到队列中。这也是会消耗服务器资源的。
我们需要让服务器实在忙不过来的时候，扔掉一些请求。以保证自己不会奔溃。该放手的时候一定要放手，不是每个人都能随随便便造一个航天飞船发上天啊。服务器真的应付不过来的时候最重要的是要保护好自己。
创建线程池的时候，可以自己指定任务队列：
*队列：就是创建队列的时候不设置大小；
有界队列：通上设置一个大小；
同步交换队列：SynchronousQueue，严格意义上说，它并不是真的队列，它只是一种数据交换的工具。任务来之后，这个队列直接把任务交给线程池中的一个线程。如果没有可用线程，则创建一个线程。如果不能创建了会拒绝这个任务。同步交换队列的核心就是它不缓存任务，要么线程池足够大，要么就直接拒绝。用于线程池可以无限增长或不会出现任务激增的场景。
可以用PriorityBlockingQueue来实现任务的排序。
饱和策略：任务队列中都存不了了怎么办
线程池提供了多种处理办法：
Abort：终止，对外抛RejectedExecutionException；
Discard：悄悄抛弃，注意是悄悄地，客户端根本不会知道自己提交的任务根本就没运行；
DiscardOldest：抛弃最老的，如果使用的是优先队列，被抛弃的会是优先级最高的那个（所以DiscardOldest不要和优先队列搭配使用）。
Caller-Runs：用客户端线程来直接运行任务代码。就是哪个线程在往线程池扔任务，那么就用这个线程来直接跑这个任务。这么做的好处是，让客户端分担线程池的负担，更主要的是让客户端先忙一会儿别的，从而暂停往线程池提交任务的动作。以期望线程池能最终缓过来。客户端都来帮着线程池做事了，那它自己的事肯定也就没人做了。如果客户端代码是一个Web请求处理程序，那么它将不再accpet新的请求，这些新的请求会被堵在TCP的缓存中，如果系统一直没有缓过劲来，再继续发展下去，就会把“过载”的信息弥漫到TCP的调用端了。整个这套设计的潜台词是“我们已经尽力了”。系统不会硬着陆直接挂掉，如果请求压力放缓，系统还是可以扛过来的。
线程工厂：定制线程
可以自己实现线程工厂来构建线程变量，从而定义更多需要的信息。
扩展ThreadPoolExecutor
ThreadPoolExecutor有一些生命周期的方法：beforeExecute、afterExecute和terminated。可以重写这些方法，实现统计和监控的功能。
递归算法的并行化
什么样的情况可以并行？
比如for循环去做一些事情，而这些事情是相互独立的。那么这些事情其实可以并行来做的（for循环是串行执行）。
这给我们的编程提供了新的思路，很多写了很多遍、平淡无奇的代码其实有更有趣的实现方式。