ExecutorService参数设置优化

参数的设置跟系统的负载有直接的关系，下面为系统负载的相关参数：

tasks，每秒需要处理的的任务数（针对系统需求）

threadtasks，每个线程每钞可处理任务数（针对线程本身）

responsetime，系统允许任务最大的响应时间，比如每个任务的响应时间不得超过2秒。

 

corePoolSize

系统每秒有tasks个任务需要处理理，则每个线程每钞可处理threadtasks个任务。，则需要的线程数为：tasks / threadtasks，即tasks/threadtasks个线程数。

假设系统每秒任务数为100 ~ 1000，每个线程每钞可处理10个任务，则需要100 / 10至1000 / 10，即10 ~ 100个线程。那么corePoolSize应该设置为大于10，具体数字最好根据8020原则，因为系统每秒任务数为100 ~ 1000，即80%情况下系统每秒任务数小于1000 * 20% = 200，则corePoolSize可设置为200 / 10 = 20

 

queueCapacity

任务队列的长度要根据核心线程数，以及系统对任务响应时间的要求有关。队列长度可以设置为 所有核心线程每秒处理任务数 * 每个任务响应时间 = 每秒任务总响应时间 ，即 (corePoolSize*threadtasks)responsetime： (20 * 10)*2=400，即队列长度可设置为400

 

maxPoolSize

当系统负载达到最大值时，核心线程数已无法按时处理完所有任务，这时就需要增加线程。每秒200个任务需要20个线程，那么当每秒达到1000个任务时，则需要

（tasks - queueCapacity）/ threadtasks 即(1000-400)/10，即60个线程，可将maxPoolSize设置为60。

队列长度设置过大，会导致任务响应时间过长，切忌以下写法：

LinkedBlockingQueue queue = new LinkedBlockingQueue();

这实际上是将队列长度设置为Integer.MAX_VALUE，将会导致线程数量永远为corePoolSize，再也不会增加，当任务数量陡增时，任务响应时间也将随之陡增。