JDK源码解析之ThreadPoolExecutor

前言：

    线程池的使用在java开发中屡见不鲜，我们一般会这样使用

// 1.创建一个固定线程数的线程池
ExecutorService threadPool = Executors.newFixedThreadPool(5);
// 2.提交任务
threadPool.submit(new Runnable() {
    @Override
    public void run() {
        // TODO
    }
});

    简简单单的两句就完成了线程池的使用和任务提交，简直太简单了有木有...

    这只是一方面，看过阿里巴巴Java开发手册的同学应该都知道，手册中对线程池的使用有一个限制（以下摘录自此手册）：

    【强制】线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。说明：Executors 返回的线程池对象的弊端如下：1）FixedThreadPool 和 SingleThreadPool:允许的请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM。2）CachedThreadPool 和 ScheduledThreadPool:允许的创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，从而导致 OOM

 

    这又是为什么呢？

    带着这个疑问，我们来看一下Executors的相关代码

 

1.Executors.newFixedThreadPool()

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue());
}

    可以看到，其直接返回了ThreadPoolExecutor的实现

 

2.ThreadPoolExecutor结构分析     1）线程池状态分析

/** 成员变量 */

// 线程池的运行状态ctl
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
private static final int COUNT_BITS = Integer.SIZE - 3;
private static final int CAPACITY   = (1