线程池参数设置问题探讨

欢迎关注同名博客：

在如今的多核处理器时代，多线程技术发挥着巨大的作用，尤其对于大批量处理同类型IO密集型的任务，例如全库全表查找数据时，多线程是提升速度和性能的利器。

今天发布的另一篇文章已经详细介绍了线程池的技术原理。但平时的开发工作中，我们可能更加关注的是线程池的使用，线程数设置多大啊？队列大小设置多大啊，等问题。

这篇文章主要是针对前段时间对线程池的使用过程中，总结了几点参数设置方面的建议，希望对大家有用。

使用多线程时，会面临 线程数，队列大小(corePoolSize maxPoolSize queueCapacity) 三个重要参数的大小设置问题。

我总结参数设置多少主要考虑下面几个方面：

一： 线程池中执行的任务性质

计算密集型的任务比较占cpu，所以一般线程数设置的大小 等于或者略微大于 cpu的核数；但IO型任务主要时间消耗在 IO等待上，cpu压力并不大，所以线程数一般设置较大，例如 多线程访问数据库，数据库有128个表，可能就直接考虑用128的线程

二： CPU使用率

当线程数设置较大时，会有如下几个问题：第一，线程的初始化，切换，销毁等操作会消耗不小的cpu资源，使得cpu利用率一直维持在较高水平。第二，线程数较大时，任务会短时间迅速执行，任务的集中执行也会给cpu造成较大的压力。第三， 任务的集中支持，会让cpu的使用率呈现锯齿状，即短时间内cpu飙高，然后迅速下降至闲置状态，cpu使用的不合理，应该减小线程数，让任务在队列等待，使得cpu的使用率应该持续稳定在一个合理，平均的数值范围。所以cpu在够用时，不宜过大，不是越大越好。可以通过上线后，观察机器的cpu使用率和cpu负载两个参数来判断线程数是否合理。可通过命令查看cpu使用率是否主要花在线程切换上。cpu负载是正在执行的线程和等待执行的线程之和，注意这个等待不是指线程的wait那种等待，而是指线程处于running状态但是还没有被cpu调度的等待，负载较高，意味着cpu竞争激烈，进而说明线程设置较大，在抢cpu资源。负载的值一般约等于 cpu核数 是比较合理的数值。

三： 内存使用率

线程数过多和 队列的大小都会影响此项数据，队列的大小应该通过前期计算线程池任务的条数，来合理的设置队列的大小，不宜过小，让其不会溢出，因为溢出会走拒绝策略，多少会影响性能，也会增加复杂度，因为你得好好考量你的拒绝策略的选择，拒绝策略包括AbortPolicy(抛异常)， CallerRunsPolicy(主线程执行) 和 DiscardPolicy(丢弃)。也不宜多大，过大用不上，还会消耗较大的内存。

四： 下游系统抗并发的能力

多线程给下游系统造成的并发等于你设置的线程数，例如如果是多线程访问数据库，你就等考虑数据库的连接池大小设置，数据库并发太多影响其qps，会把数据库打挂等问题。 如果访问的是下游系统的接口，你就得考虑下游系统是否能抗的住这么多并发量，不能把下游系统打挂了。