线程池的长度取决于未来提交的任务类型和所部署的系统特征。
概述
制定线程池的长度并不是一门精密的科学，需要做的仅仅是避免“过大”和“过小”者两个极端情况。如果一个线程池过大，那么线程对稀缺的CPU和内存资源的竞争，会导致内存的高使用量，还可能耗尽资源。如果过小，由于存在很多可用的处理器资源却未在工作，会对吞吐量造成损失。
为了正确地制定线程池的长度，需要理解当前的计算环境、资源预算和任务的自身特性。部署系统中安装了多少个CUP？多少内存？任务主要执行的是计算、I/O还是一些混合操作？它们知否需要像JDBCConnection这样的稀缺资源？如果有不同类别的任务，它们拥有差别很大很为，那么可以考虑使用多个线程池，这样每个线程池可以根据不同任务的工作负载进行调节。
估算
一般说来，大家认为线程池的大小经验值应该这样设置：（其中N为CPU的个数）
- 如果是CPU密集型应用，则线程池大小设置为N 1
- 如果是IO密集型应用，则线程池大小设置为2N 1
如果一台服务器上只部署这一个应用并且只有这一个线程池，那么这种估算或许合理，具体还需自行测试验证。 但是，IO优化中，这样的估算公式可能更适合：
- 最佳线程数目 = （（线程等待时间 线程CPU时间）/线程CPU时间 ）* CPU数目
因为很显然，线程等待时间所占比例越高，需要越多线程。线程CPU时间所占比例越高，需要越少线程。
下面举个例子：比如平均每个线程CPU运行时间为0.5s，而线程等待时间（非CPU运行时间，比如IO）为1.5s，CPU核心数为8，那么根据上面这个公式估算得到：((0.5 1.5)/0.5)*8=32。这个公式进一步转化为：
- 最佳线程数目 = （线程等待时间与线程CPU时间之比 1）* CPU数目
刚刚说到的线程池大小的经验值，其实是这种公式的一种估算值。
参考 如何合理地估算线程池大小？
