【Java 线程池】【十】线程池篇总结以及为什么不提倡使用Executors来构建线程池

3  为什么不建议使用Executors来构建线程池

接下来我们讲解一下JDK提供的Executors这个工具类，提供创建线程池的几个方法，之前我们讲解的时候不建议使用Executors来构建线程池，我们来分析一下为什么：

3.1  newCachedThreadPool 方法

public static ExecutorService newCachedThreadPool() {
    return new ThreadPoolExecutor(0,
                          Integer.MAX_VALUE,
                          60L,
                          TimeUnit.SECONDS,
                    new SynchronousQueue<Runnable>());
}

这里注意 corePoolSize为0，maximumPoolSize为MAX_VALUE、阻塞队列是SynchronousQueue
（1）由于当前线程数始终大于等于0，也就是当前线程数 >= corePoolSize永远成立
（2）所以提交任务的时候，优先提交到阻塞队列中
（3）队列使用的是SynchronousQueue同步队列，这种队列的特点之前在并发数据容器篇的时候已经深入分析过了；
只有当别的线程正在调用poll方法或者take方法的时候，当前线程调用offer方法才会成功。
（4）所以最开始是任务放入阻塞队列是失败的，就会触发另外一个条件，线程数 < MAX_VALUE能创建线程成功。
（5）这就导致，如果一下子提交非常多的任务，会创建非常多的线程
（6）线程数量太多，cpu竞争剧烈，可能cpu 100%；同时由于每个线程数量需要占用一定内存，默认1M，所以可能导致内存资源耗尽而OOM

3.2  newFixdThreadPool 方法

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

最小、最大线程数为nThreads，也就是线程数是固定的，非常注意的是这里使用的是LinkedBlocingQueue无界阻塞队列
（1）线程数量 < corePoolSize，提交任务会创建新线程
（2）当线程数量达到 corePoolSize时候，提交任务会尝试存入阻塞队列中
（3）非常要注意这里LinkedBlockingQueue使用的是默认构造函数，阻塞队列最大容量是Integer.MAX_VALUE，相当于容量没有限制
（4）如此会造成大量任务进入LinkedBlockingQueue队列，而其又在内存中，会造成OOM
（5）很常见的情况，我们线程就有过几次由于开发人员对LinkedBlockingQueue容量设置没有上限、或者设置过大而造成的OOM事故，这里要非常注意

3.3  newSingleThreadExecutor 方法

public static ExecutorService newSingleThreadExecutor() {
    return new FinalizableDelegatedExecutorService
        (new ThreadPoolExecutor(1,
                           1,
                    0L, TimeUnit.MILLISECONDS,
                     new LinkedBlockingQueue<Runnable>()));
}

这里使用的一样是LinkedBlockingQueue无界队列（容量大小没有限制，默认是Integer.MAX_VALUE），一样会导致上面的问题。

3.4  newScheduledThreadPool 方法

public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
    return new ScheduledThreadPoolExecutor(corePoolSize);
}

public ScheduledThreadPoolExecutor(int corePoolSize) {
    // 内部调用父类ThreadPoolExecutor线程的构造方法
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
          new DelayedWorkQueue());
}

这里使用的是DelayedWorkQueue延迟队列，这个队列的offer方法提交任务的时候也是没有大小限制的，如果数组大小不够就会扩容，这种情况也可能大量的任务积压在DelayedWorkQueue内存队列，从而造成OOM。
还有这里的ScheduledThreadPoolExecutor使用要比较谨慎一点，插入删除任务的复杂度我们上节对比过了，不适合提交大量的任务，会造成大量任务积压而OOM，比较适合一些任务比较少，一些少量的定时任务、延迟任务等情况。

说白了其实就是因为这些Executors创建的线程池要么就是最大线程数量设置没有上限、要么就是阻塞队列的容量设置没有上限，都有很大的风险。

4  小结

好了，关于线程池的我们就看这么多哈，技术没有捷径就是要多看多用多写，其实什么事情都是如此，多尝试多发现多思考哈，有理解不对的地方欢迎指正哈。