接深入浅出多线程系列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来配置扩展来实现个性化需求的线程池。