接深入浅出多线程系列4，
线程对象的创建和销毁是需要花费系统资源的，通过线程池，可以避免该问 题并提高系统的响应时间。这种情形类似我们常提到的数据库连接池。
线程池的广泛应用使得在SUN在JDK 1.5的工具包提供了线程池的支持。我计 划将该系列分为设计需求与设计实现两个部分。这样会更加清晰。如果想要熟悉 ，并熟练应用线程池，那么通过设计需求篇也就是该篇就可以找到答案。如果想 探究实现的细节，那么在设计实现篇会有深入的说明。
本文以Concurrent包线程池设计为例，讨论线程池的设计。
线程池需求
设计与实现的最终目标是满足需求，这是软件开发的基本原则。我们先考虑 考虑对线程池的需求。作为一名开发人员，我们最主要的需求就是线程池简单， 易用。即使你的设计算法多么优雅，但给使用者复杂的使用步骤也是得不偿失， 简单就是美！最好我们不用深究你的具体实现，通过简单的接口就可以应用。其 次就是技术角度，线程池的设计应该是比较柔性的，提供很好的可配置可管理与 可扩张性。
对于可配置可管理的需求，至少的提供以下的功能点：
线程池里，线程数量的配置。
能够提供动态调整线程的数量。
能够Shutdown 最好能够提供优雅的Shundown，而不是像我们通过切断电源关 闭机器那样粗暴的Shutdown。
能够提供Task的状态，比如完成了多少，还有多少没有完成。
对于可扩展性而言有以下几点：
如果不能满足需要能够很容易的扩展。
对于线程池线程的创建能否提够扩展。
当提交的Task负载过大时，线程池的处理策略能否扩展。
以上是对线程池的需求的讨论。
2.上面就这些对于我们使用者而言，对线程池的需求，下面我们分析 Concurrent包提供的线程池是否达到了我们的需求。
对于易用的需求。
Concurrent的ExecuTors类，注意不是ExecuTor接口，通过FacTory模式提供 了我们以下的基本的线程池，如果没有
特殊的需求，只需查阅这几个线程池JDK文档，就可以使用了。
newFixedThreadPool 顾名思义，建立固定大小的线程池。
newCachedThreadPool 根据需要动态的创建线程，该线程池我们在深入系列4 做了讨论。
newSingleThreadExecuTor 如其名。
newScheduledThreadPool 如其名，该线程池类似于JDK1.4 Timer提供的功 能，但更完善，我会在随后的深入浅出系列讨论其不同 点。
总之，从易用性的角度见，Concurrent包提供的接口是不错的。
对于可配置，可管理讲：
提供了可以配置线程池中线程的数量的功能。比如在创建 newFixedThreadPool时，第一个参数就是线程池线程的数量，通过
该数量的配置，我们就可以保证不会因为线程的过多导致系统的崩溃。
提供了在运行时通过setCorePoolSize和setMaximumPoolSize方法来调整线程 池数量的功能，两者的区别会在后续实现篇中说明。
提够了优雅的Shutdown，不在接受Task，将正在运行的Task执行完，处于等 待状态的Task 中断。
提供getTaskCount和getCompletedTaskCount方法可以获取提交的Task和完成 的Task数量。
对于可扩展性
我们可以参考ExecuTors的FacTory模式，扩展提供满足需要的线程池。
在构造方法中，提供ThreadFacTory接口，我们可以实现自定义的创建线程池 线程的方法。
提供了RejectedExecutionHandler接口，我们可以扩张该接口，提供当Task 过多时，处理策略，目前默认为AbortPolicy策略Throw 一个 RejectedExecutionException
总之，Concurrent中ExecuTors类通过FacTory Method方法，提供了基本常用 的线程池。 ExecuTors 其实通过线程池实现类-ThreadPoolExecuTor创建基本的 线程池，所以我们可以通过ThreadPoolExecuTor提供的API来配置扩展来实现个 性化需求的线程池。
或许是某座闻名遐迩的文化古城。我们可以沿途用镜头记录彼此的笑脸，
