大家好，又见面了，我是你们的朋友全栈君。

在线程池的实际使用中，参数的配置总让人难以把握。在网上搜了一下，主要有以下的方案。跟大家分享。

1. 基本概念

1.1 ThreadPoolExecutor的重要参数

corePoolSize：核心线程数

• 核心线程会一直存活，及时没有任务需要执行
• 当线程数小于核心线程数时，即使有线程空闲，线程池也会优先创建新线程处理
• 设置allowCoreThreadTimeout=true（默认false）时，核心线程会超时关闭

queueCapacity：任务队列容量（阻塞队列）

• 当核心线程数达到最大时，新任务会放在队列中排队等待执行

maxPoolSize：最大线程数

• 当线程数>=corePoolSize，且任务队列已满时。线程池会创建新线程来处理任务
• 当线程数=maxPoolSize，且任务队列已满时，线程池会拒绝处理任务而抛出异常

keepAliveTime：线程空闲时间

• 当线程空闲时间达到keepAliveTime时，线程会退出，直到线程数量=corePoolSize
• 如果allowCoreThreadTimeout=true，则会直到线程数量=0

allowCoreThreadTimeout：允许核心线程超时
rejectedExecutionHandler：任务拒绝处理器

• 两种情况会拒绝处理任务：
• 当线程数已经达到maxPoolSize，切队列已满，会拒绝新任务
• 当线程池被调用shutdown()后，会等待线程池里的任务执行完毕，再shutdown。如果在调用shutdown()和线程池真正shutdown之间提交任务，会拒绝新任务
• 线程池会调用rejectedExecutionHandler来处理这个任务。如果没有设置默认是AbortPolicy，会抛出异常

ThreadPoolExecutor类有几个内部实现类来处理这类情况：

• AbortPolicy 丢弃任务，抛运行时异常
• CallerRunsPolicy 执行任务
• DiscardPolicy 忽视，什么都不会发生
• DiscardOldestPolicy 从队列中踢出最先进入队列（最后一个执行）的任务

实现RejectedExecutionHandler接口，可自定义处理器

1.2 ThreadPoolExecutor执行顺序

1. 当线程数小于核心线程数时，创建线程。
2. 当线程数大于等于核心线程数，且任务队列未满时，将任务放入任务队列。
3. 当线程数大于等于核心线程数，且任务队列已满
   1. 若线程数小于最大线程数，创建线程
   2. 若线程数等于最大线程数，抛出异常，拒绝任务

2. 基本分析法

要想合理的配置线程池，就必须首先分析任务特性，可以从以下几个角度来进行分析：

1. 任务的性质：CPU密集型任务，IO密集型任务和混合型任务。
2. 任务的优先级：高，中和低。
3. 任务的执行时间：长，中和短。
4. 任务的依赖性：是否依赖其他系统资源，如数据库连接。

2.1 任务性质不同的任务

任务性质不同的任务可以用不同规模的线程池分开处理。

2.1.1 CPU密集型任务

CPU密集型任务配置尽可能少的线程数量，如配置cpu核数+1个线程能够实现最优的CPU利用率，+1是保证当线程由于页缺失故障（操作系统）或其它原因导致暂停时，额外的这个线程就能顶上去，保证CPU的时钟周期不被浪费。

2.1.2 IO密集型任务

IO密集型任务则由于需要等待IO操作，CPU不总是处于繁忙状态。则配置尽可能多的线程，利用多线程提高CPU的利用率。经验公式如下：

线程数 = 核数 * 期望 CPU 利用率 * 总时间(CPU计算时间+等待时间) / CPU 计算时间

例如 4 核 CPU 计算时间是 50% ，其它等待时间是 50%，期望 cpu 被 100% 利用，

套用公式 4 * 100% * 100% / 50% = 8

例如 4 核 CPU 计算时间是 10% ，其它等待时间是 90%，期望 cpu 被 100% 利用，

套用公式 4 * 100% * 100% / 10% = 40

2.1.3 混合型的任务

混合型的任务，如果可以拆分，则将其拆分成一个CPU密集型任务和一个IO密集型任务，只要这两个任务执行的时间相差不是太大，那么分解后执行的吞吐率要高于串行执行的吞吐率，如果这两个任务执行时间相差太大，则没必要进行分解。我们可以通过Runtime.getRuntime().availableProcessors()方法获得当前设备的CPU个数。

2.2 优先级不同的任务

优先级不同的任务可以使用优先级队列PriorityBlockingQueue来处理。它可以让优先级高的任务先得到执行，需要注意的是如果一直有优先级高的任务提交到队列里，那么优先级低的任务可能永远不能执行。

2.3 执行时间不同的任务

执行时间不同的任务可以交给不同规模的线程池来处理，或者也可以使用优先级队列，让执行时间短的任务先执行。

2.4 依赖数据库连接池的任务

依赖数据库连接池的任务，因为线程提交SQL后需要等待数据库返回结果，如果等待的时间越长CPU空闲时间就越长，那么线程数应该设置越大，这样才能更好的利用CPU。

并且，阻塞队列最好是使用有界队列，如果采用无界队列的话，一旦任务积压在阻塞队列中的话就会占用过多的内存资源，甚至会使得系统崩溃。

3. 估值计算法

3.1 默认值

• corePoolSize=1
• queueCapacity=Integer.MAX_VALUE
• maxPoolSize=Integer.MAX_VALUE
• keepAliveTime=60s
• allowCoreThreadTimeout=false
• rejectedExecutionHandler=AbortPolicy()

3.2 如何来设置

需要根据几个值来决定：

• tasks ：每秒的任务数，假设为500~1000
• taskcost：每个任务花费时间，假设为0.1s
• responsetime：系统允许容忍的最大响应时间，假设为1s

做几个计算：

corePoolSize = 每秒需要多少个线程处理？ 

• threadcount = tasks/(1/taskcost) =tasks*taskcout =  (500~1000)*0.1 = 50~100 个线程。corePoolSize设置应该大于50
• 根据8020原则，如果80%的每秒任务数小于800，那么corePoolSize设置为80即可

queueCapacity = (coreSizePool/taskcost)*responsetime

• 计算可得 queueCapacity = 80/0.1*1 = 80。意思是队列里的线程可以等待1s，超过了的需要新开线程来执行
• 切记不能设置为Integer.MAX_VALUE，这样队列会很大，线程数只会保持在corePoolSize大小，当任务陡增时，不能新开线程来执行，响应时间会随之陡增。

maxPoolSize = (max(tasks)- queueCapacity)/(1/taskcost)

• 计算可得 maxPoolSize = (1000-80)/10 = 92
• （最大任务数-队列容量）/每个线程每秒处理能力 = 最大线程数

rejectedExecutionHandler：根据具体情况来决定，任务不重要可丢弃，任务重要则要利用一些缓冲机制来处理

keepAliveTime和allowCoreThreadTimeout采用默认通常能满足

以上都是理想值，实际情况下要根据机器性能来决定。如果在未达到最大线程数的情况机器cpu load已经满了，则需要通过升级硬件（呵呵）和优化代码，降低taskcost来处理。