线程池参数设置

原文：https://blog.csdn.net/zhanht/article/details/79513134 

 

在如今的多核处理器时代，多线程技术发挥着巨大的作用，尤其对于大批量处理同类型IO密集型的任务，例如全库全表查找数据时，多线程是提升速度和性能的利器。
      近期发布的另一篇文章已经详细介绍了线程池的技术原理。但平时的开发工作中，我们可能更加关注的是线程池的使用，线程数设置多大啊？队列大小设置多大啊，等问题。
      这篇文章主要是针对前段时间对线程池的使用过程中，总结了几点参数设置方面的建议，希望对大家有用。
      使用多线程时，会面临 线程数，队列大小(corePoolSize  maxPoolSize  queueCapacity) 三个重要参数的大小设置问题。
      我根据自己前期的工作总结发现参数设置主要考虑下面几个方面：
1. 线程池中执行的任务性质。

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

2. CPU使用率。

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

3. 内存使用率。

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

4. 下游系统抗并发的能力。

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

下面介绍一个大家很容易犯的错误，场景如下：

线程池的配置如下：

    
    
    

现在发现任务执行的比较慢，机器的cpu，内存等也还较低，因此决定加大线程，估算了下，大概需要100个线程，于是把配置改为如下：

    
    
    

大家有发现什么问题吗？

问题在于，线程池是否创建新的线程，考虑如下：(1) 如果线程数小于corePoolSize,直接添加新的线程; (2) 如果大于等于corePoolSize，则放进队列进行等待，如果入队成功，则不添加新的线程(除非此时没有了工作线程，则会新建个用来处理对列里的任务)； (3) 如果对列满了，线程数小于maxPoolSize，则会新建线程，如果大于maxpoolSize，则会走到拒绝策略。
因为队列设置的比较大，基本上不会满，所以线程数其实是一致达不到maxPoolSize的，所以，其实一致用的是50个线程。

解决方法：把核心线程和最大线程设置成一个值，都为100即可。
测试代码截图如下：