线程池是 Java 并发编程中不可缺少的一部分。JDK 提供了一个方便快捷的线程池工具类 Executors，提供了多种创建线程池的静态方法，但是在实际使用中，我们不建议直接使用 Executors 提供的线程池工具类。本篇博客将通过分析 Executors 源码，介绍为什么不推荐使用 Executors 线程池。
newCachedThreadPool
/**
* 创建一个线程池，根据需要创建新线程，但在以前构造的线程可用时重用它们。
* 这些池通常会提高执行许多短期异步任务的程序的性能。对execute的调用将重用先前构造的线程(如果可用)。
* 如果没有可用的线程，将创建一个新线程并将其添加到池中。60秒内未使用的线程将被终止并从缓存中删除。
* 因此，空闲时间足够长的池不会消耗任何资源。
* @return the newly created thread pool
*/
public static ExecutorService newCachedThreadPool() {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue<Runnable>());
}从源码中可以看出，newCachedThreadPool的核心线程为0，最大线程数为Integer.MAX_VALUE，队列为SynchronousQueue，该队列要求只有线程获取任务的话才能加入队列中。如果线程池的大小超过处理任务的线程，那么就会回收空闲线程。因为该线程池的最大线程数量为 Integer.MAX_VALUE，任务量过多时，可能会创建大量的线程，从而导致 OOM。
newFixedThreadPool(int nThreads)
/**
* 创建一个线程池，该线程池重用固定数量的线程，这些线程在共享无界队列上操作。
* 在任何时候，最多nThreads线程将是活动的处理任务。
* 如果在所有线程都处于活动状态时提交了额外的任务，它们将在队列中等待，直到有一个线程可用。
* 任何线程在关闭之前的执行过程中由于失败而终止，如需要执行后续任务，将会有一个新的线程取代它的位置。
* 在显式关闭池之前，池中的线程将一直存在。
* @param nThreads the number of threads in the pool
* @return the newly created thread pool
* @throws IllegalArgumentException if {@code nThreads <= 0}
*/
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>());
}从newFixedThreadPool源码可以看出,该方法会创建一个固定大小的线程池。核心线程数和最大线程数一致,当接受一个任务后就创建一个线程直至达到最大线程数。此时会将任务加入工作队列中工作队列采用的是无界的阻塞队列，支持先提交的先执行。因为LinkedBlockingQueue队列是无参构造，默认最大可存放请求数为 Integer.MAX_VALUE ，当任务量过多时，可能会导致大量任务堆积到队列中，从而导致 OOM。
newSingleThreadExecutor()
/**
* 创建一个Executor，该Executor使用单个工作线程对无界队列进行操作。
* (但是请注意，如果这个线程在关闭之前的执行期间由于失败而终止，如果需要执行后续任务，
* 将会有一个新的线程取代它的位置。)
* 任务保证按顺序执行，并且在任何给定时间活动的任务不超过一个。与newFixedThreadPool(1)不同，
* 返回的执行器保证不能重新配置以使用其他线程。
* @return the newly created single-threaded Executor
*/
public static ExecutorService newSingleThreadExecutor() {
return new FinalizableDelegatedExecutorService
(new ThreadPoolExecutor(1, 1,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<Runnable>()));
}从newSingleThreadExecutor源码中可以看到核心线程数是1，最大线程数也是1，队列采用的是无界的LinkedBlockingQueue阻塞队列。如果核心线程异常的话，则创建一个线程去顶替核心线程(但始终保持单线程)，因为队列是无参构造，默认最大可存放请求数为 Integer.MAX_VALUE ，当任务量过多时，可能会导致大量任务堆积到队列中，从而导致 OOM。
newScheduledThreadPool(int corePoolSize)
/**
* 创建一个线程池，该线程池可以安排命令在给定延迟后运行，或定期执行。
* @param corePoolSize the number of threads to keep in the pool,
* even if they are idle
* @return a newly created scheduled thread pool
* @throws IllegalArgumentException if {@code corePoolSize < 0}
*/
public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {
return new ScheduledThreadPoolExecutor(corePoolSize);
}
//ScheduledThreadPoolExecutor源码
public ScheduledThreadPoolExecutor(int corePoolSize) {
super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
new DelayedWorkQueue());
}newScheduledThreadPool线程池是支持定时任务的线程池，可以指定核心线程数，最大线程数为Interger.MAX_VALUE，内部使用的是：DelayedWorkQueue无界优先级阻塞队列。要求元素都实现 Delayed 接口。因为该线程池的最大线程数量为 Integer.MAX_VALUE，任务量过多时，可能会创建大量的线程，从而导致 OOM。
总结
Executors是JDK提供的一个线程池工具类，可以通过Executors提供的静态方法来创建不同类型的线程池。虽然Executors使用起来方便快捷，但是在实际应用中并不推荐直接使用，主要原因如下：
-
线程池参数的默认值不合理：Executors提供的默认线程池参数，在很多情况下并不是最优的选择。例如FixedThreadPool和SingleThreadPool中的队列大小都为Integer.MAX_VALUE，这会导致大量任务排队等待，从而触发OOM导致服务宕机。newCachedThreadPool和newScheduledThreadPool会创建一个可缓存线程池，没有固定的线程数限制，如果有新的任务需要执行，则会创建新的线程去执行任务。而当线程池空闲一段时间后，创建的线程将会被销毁。如果同时有大量请求到达，在新线程创建之前，可能会导致服务端过多的线程，从而造成系统资源的浪费和CPU负载过高。在实际应用中，我们往往需要根据实际情况来设置合理的线程数和队列大小。
-
线程池的创建方式不利于优化和扩展：Executors提供的线程池创建方式较为简单，不支持对线程池进行细粒度的配置和优化。如果需要根据具体需求进行调整，可能需要重新编写线程池实现代码，而这通常会涉及到复杂的多线程操作和同步控制。
-
线程池的抛弃策略处理不够友好：当线程池中的队列已满，无法再提交新任务时，线程池的默认抛弃策略是AbortPolicy，即直接抛出RejectedExecutionException异常。这样会导致服务直接崩溃，无法处理后续请求。而通过自定义抛弃策略，可以对任务进行缓存、持久化等操作，以便后续再次尝试执行。
因此，为了更好的控制线程池的行为、实现更细粒度的优化和扩展，并且避免由于线程池配置不合理或者抛弃策略不友好，造成服务宕机等问题，建议开发人员采用手动编写线程池方式，根据实际情况进行调整并实现线程池的自定义扩展功能。
自定义线程池参考文章：
SpringBoot + @Async 使用自定义线程池实现多线程任务处理
Spring异步注解@Async
