聊一聊一道关于线程池的面试题

网络上有这样一道关于线程池的面试题：

1. 高并发、任务执行时间短的业务怎样使用线程池？

2. 并发不高、任务执行时间长的业务怎样使用线程池？

3. 并发高、业务执行时间长的业务怎样使用线程池？

请读者思考下，如果你在面试中遇到这样的问题该如何作答。

当然，如果你仅把它当做面试题，那就太遗憾了， 这是一个非常好的问题，能反映出开发者对线程池的理解深入程度以及对高性能服务结构的设计能力。

线程池本质上是生产者和消费者模型，包括三要素：

• 往线程池队列中投递任务的生产者；

• 任务池队列；

• 从任务池队列取出任务执行的 worker 线程（消费者）。

要想合理的配置线程池的大小，得分析线程池任务的特性，可以从以下几个方面来分析：

根据任务的性质来分：

• CPU 密集型任务；

• IO 密集型任务；

• 混合型任务。

根据任务的优先级：

• 高

• 中

• 低

根据任务的执行时间：

• 长

• 中

• 短

不同性质的任务可以交给不同配置的线程池执行。

对于不同性质的任务来说，CPU 密集型任务应配置尽可能小的线程，如配置 CPU 个数 + 1的线程数；IO 密集型任务应配置尽可能多的线程，因为 IO 操作不占用 CPU，不要让 CPU 闲下来，应加大线程数量，如配置两倍 CPU 个数 + 1；而对于混合型的任务，如果可以拆分，拆分成 IO 密集型和 CPU 密集型分别处理，前提是两者运行的时间是差不多的，如果处理时间相差很大，则没必要拆分了。

如果任务执行时间长，在 worker 线程数量有限的情况下，worker 很快就很被任务占完，导致后续任务不能及时被处理，此时应适当增加 worker 线程数量；反过来，如果任务执行时间短，那么 worker 线程数量不用太多，太多的 worker 线程会导致过多的时间浪费在线程上下文切换上。

回到这个问题本身来，这里的“高并发”应该是生产者生产任务的速度比较快，此时需要适当增大任务队列上限。

但是对于第三个问题并发高、业务执行时间长这种情形单纯靠线程池解决方案是不合适的，即使服务器有再高的资源配置，每个任务长周期地占用着资源，最终服务器资源也会很快被耗尽，因此对于这种情况，应该配合业务解耦，做些模块拆分优化整个系统结构。

关于线程池的设计，推荐给想提高的同学可以好好研究一下 JDK 的 ThreadExecutorPool 类及其几种线程池模式。

推荐阅读：

原创不易，点个在看呗~