背景

前段时间一个项目中因为涉及大量的线程开发，把jdk cocurrent的代码重新再过了一遍。这篇文章中主要是记录一下学习ThreadPoolExecutor过程中容易被人忽略的点，Doug Lea的整个类设计还是非常nice的

 

正文

先看一副图，描述了ThreadPoolExecutor的工作机制: 

 

整个ThreadPoolExecutor的任务处理有4步操作：

 

• 第一步，初始的poolSize < corePoolSize，提交的runnable任务，会直接做为new一个Thread的参数，立马执行
• 第二步，当提交的任务数超过了corePoolSize，就进入了第二步操作。会将当前的runable提交到一个block queue中
  
• 第三步，如果block queue是个有界队列，当队列满了之后就进入了第三步。如果poolSize < maximumPoolsize时，会尝试new 一个Thread的进行救急处理，立马执行对应的runnable任务
• 第四步，如果第三步救急方案也无法处理了，就会走到第四步执行reject操作。

几点说明：(相信这些网上一搜一大把，我这里简单介绍下，为后面做一下铺垫)

• block queue有以下几种实现：
  1. ArrayBlockingQueue :  有界的数组队列
  2. LinkedBlockingQueue : 可支持有界/无界的队列，使用链表实现
  3. PriorityBlockingQueue : 优先队列，可以针对任务排序
  4. SynchronousQueue : 队列长度为1的队列，和Array有点区别就是：client thread提交到block queue会是一个阻塞过程，直到有一个worker thread连接上来poll task。
• RejectExecutionHandler是针对任务无法处理时的一些自保护处理：
  1. Reject 直接抛出Reject exception
  2. Discard 直接忽略该runnable，不可取
  3. DiscardOldest 丢弃最早入队列的的任务
  4. CallsRun 直接让原先的client thread做为worker线程，进行执行

容易被人忽略的点：

1.  pool threads启动后，以后的任务获取都会通过block queue中，获取堆积的runnable task.

所以建议： block size >= corePoolSize ，不然线程池就没任何意义

2.  corePoolSize 和 maximumPoolSize的区别， 和大家正常理解的数据库连接池不太一样。

  *  据dbcp pool为例，会有minIdle , maxActive配置。minIdle代表是常驻内存中的threads数量，maxActive代表是工作的最大线程数。

  *  这里的corePoolSize就是连接池的maxActive的概念，它没有minIdle的概念(每个线程可以设置keepAliveTime，超过多少时间多有任务后销毁线程，但不会固定保持一定数量的threads)。 

  * 这里的maximumPoolSize，是一种救急措施的第一层。当threadPoolExecutor的工作threads存在满负荷，并且block queue队列也满了，这时代表接近崩溃边缘。这时允许临时起一批threads，用来处理runnable，处理完后立马退出。

所以建议：  maximumPoolSize >= corePoolSize =期望的最大线程数。 (我曾经配置了corePoolSize=1, maximumPoolSize=20, blockqueue为无界队列，最后就成了单线程工作的pool。典型的配置错误)

3. 善用blockqueue和reject组合. 这里要重点推荐下CallsRun的Rejected Handler，从字面意思就是让调用者自己来运行。

我们经常会在线上使用一些线程池做异步处理，比如我前面做的(业务层)异步并行加载技术分析和设计, 将原本串行的请求都变为了并行操作，但过多的并行会增加系统的负载(比如软中断，上下文切换)。所以肯定需要对线程池做一个size限制。但是为了引入异步操作后，避免因在block queue的等待时间过长，所以需要在队列满的时，执行一个callsRun的策略，并行的操作又转为一个串行处理，这样就可以保证尽量少的延迟影响。

所以建议：  RejectExecutionHandler = CallsRun ,  blockqueue size = 2 * poolSize (为啥是2倍poolSize，主要一个考虑就是瞬间高峰处理，允许一个thread等待一个runnable任务)

Btrace容量规划

再提供一个btrace脚本，分析线上的thread pool容量规划是否合理，可以运行时输出poolSize等一些数据。

 

 

import static com.sun.btrace.BTraceUtils.addToAggregation;
import static com.sun.btrace.BTraceUtils.field;
import static com.sun.btrace.BTraceUtils.get;
import static com.sun.btrace.BTraceUtils.newAggregation;
import static com.sun.btrace.BTraceUtils.newAggregationKey;
import static com.sun.btrace.BTraceUtils.printAggregation;
import static com.sun.btrace.BTraceUtils.println;
import static com.sun.btrace.BTraceUtils.str;
import static com.sun.btrace.BTraceUtils.strcat;

import java.lang.reflect.Field;
import java.util.concurrent.atomic.AtomicInteger;

import com.sun.btrace.BTraceUtils;
import com.sun.btrace.aggregation.Aggregation;
import com.sun.btrace.aggregation.AggregationFunction;
import com.sun.btrace.aggregation.AggregationKey;
import com.sun.btrace.annotations.BTrace;
import com.sun.btrace.annotations.Kind;
import com.sun.btrace.annotations.Location;
import com.sun.btrace.annotations.OnEvent;
import com.sun.btrace.annotations.OnMethod;
import com.sun.btrace.annotations.OnTimer;
import com.sun.btrace.annotations.Self;

/**
 * 并行加载监控
 * 
 * @author jianghang 2011-4-7 下午10:59:53
 */
@BTrace
public class AsyncLoadTracer {

    private static AtomicInteger rejecctCount = BTraceUtils.newAtomicInteger(0);
    private static Aggregation   histogram    = newAggregation(AggregationFunction.QUANTIZE);
    private static Aggregation   average      = newAggregation(AggregationFunction.AVERAGE);
    private static Aggregation   max          = newAggregation(AggregationFunction.MAXIMUM);
    private static Aggregation   min          = newAggregation(AggregationFunction.MINIMUM);
    private static Aggregation   sum          = newAggregation(AggregationFunction.SUM);
    private static Aggregation   count        = newAggregation(AggregationFunction.COUNT);

    @OnMethod(clazz = "java.util.concurrent.ThreadPoolExecutor", method = "execute", location = @Location(value = Kind.ENTRY))
    public static void executeMonitor(@Self Object self) {
        Field poolSizeField = field("java.util.concurrent.ThreadPoolExecutor", "poolSize");
        Field largestPoolSizeField = field("java.util.concurrent.ThreadPoolExecutor", "largestPoolSize");
        Field workQueueField = field("java.util.concurrent.ThreadPoolExecutor", "workQueue");

        Field countField = field("java.util.concurrent.ArrayBlockingQueue", "count");
        int poolSize = (Integer) get(poolSizeField, self);
        int largestPoolSize = (Integer) get(largestPoolSizeField, self);
        int queueSize = (Integer) get(countField, get(workQueueField, self));

        println(strcat(strcat(strcat(strcat(strcat("poolSize : ", str(poolSize)), " largestPoolSize : "),
                                     str(largestPoolSize)), " queueSize : "), str(queueSize)));
    }

    @OnMethod(clazz = "java.util.concurrent.ThreadPoolExecutor", method = "reject", location = @Location(value = Kind.ENTRY))
    public static void rejectMonitor(@Self Object self) {
        String name = str(self);
        if (BTraceUtils.startsWith(name, "com.alibaba.pivot.common.asyncload.impl.pool.AsyncLoadThreadPool")) {
            BTraceUtils.incrementAndGet(rejecctCount);
        }
    }

    @OnTimer(1000)
    public static void rejectPrintln() {
        int reject = BTraceUtils.getAndSet(rejecctCount, 0);
        println(strcat("reject count in 1000 msec: ", str(reject)));
        AggregationKey key = newAggregationKey("rejectCount");
        addToAggregation(histogram, key, reject);
        addToAggregation(average, key, reject);
        addToAggregation(max, key, reject);
        addToAggregation(min, key, reject);
        addToAggregation(sum, key, reject);
        addToAggregation(count, key, reject);
    }

    @OnEvent
    public static void onEvent() {
        BTraceUtils.truncateAggregation(histogram, 10);
        println("---------------------------------------------");
        printAggregation("Count", count);
        printAggregation("Min", min);
        printAggregation("Max", max);
        printAggregation("Average", average);
        printAggregation("Sum", sum);
        printAggregation("Histogram", histogram);
        println("---------------------------------------------");
    }
}

 

运行结果：

 

poolSize : 1 , largestPoolSize = 10 , queueSize = 10
reject count in 1000 msec: 0

 

说明：

1. poolSize 代表为当前的线程数

2. largestPoolSize 代表为历史最大的线程数

3. queueSize 代表blockqueue的当前堆积的size

4. reject count 代表在1000ms内的被reject的数量

 

 

最后

  这是我对ThreadPoolExecutor使用过程中的一些经验总结，希望能对大家有所帮助，如有描述不对的地方欢迎拍砖。

如果每天有十万条线程需运行，用这个方法可不可靠？就是如果出错，之前的数据就丢失了，因为不象JMS那样，有保存的功能。

ThreadPoolExecutor不会帮你执行数据的持久化，它只是一个工具，一个执行器

你提的需求，应该需要一整套的技术来完成你需要的高可用的需求，而ThreadExecutorPool更面向的应该是单机高性能的处理, jdk cocurrent包中的基本都是这个定位

如果每天十万条线程这种级别的，是否建议使用ThreadExecutorPool？

10W个线程 or 10W个任务？ jvm线程创建需要占用一定的内存，普通服务器不可能创建达到上W级的线程。

就是queueSize这里可能有十万条处于等待中。

1. 如果10W条，评估下内存占用，不暴jvm内存的话，完全没啥问题
2. 如果内存占用过大，可考虑扩展实现一个RejectedExecutionHandler，出现满任务时hold住后续的任务提交，进行一个阻塞操作

好主意!
另,Doug Lea大师的设计非常非常棒,
比如
RejectedExecutionHandler中的
4. CallsRun 直接让原先的client thread做为worker线程，进行执行
仅在当前线程上下文中执行该runnable的run()方法
即非常巧妙有趣的处理了RejectedExecution
很帅啊,谁说runnable/thread只能start呢?

如果正在执行的task是个很耗时的任务,且它没有安乐死的方法.这是用户已经没有耐心在继续等待了,也不想让它继续占用线程池的工作线程;所以想强杀所在线程(强杀无副作用:不会造成死锁资源泄露等),然后再补缺.大家觉得这样的线程池怎么样?

线程池应该还要提供一种策略给我们选择----是优先启动新线程还是优先使用队列。否则用有界或是无界队列，都是先把队列填满了才再开新线程。导致的一个结果是我们不得不用SynchronousQueue来作为任务队列。