当前位置：首页 > ds >正文

Java线程池的几个常见问题

ds 2025/9/6 13:55:07

Java通过Executors工厂类提供了几种快速创建线程池的便捷方法。这些方法内部都是通过ThreadPoolExecutor或ForkJoinPool的不同参数配置来实现的。

主要实现有：

1、newFixedThreadPool(int nThreads)

2、newCachedThreadPool()

特点：创建一个可缓存的线程池。核心线程数为0，最大线程数为Integer.MAX_VALUE。使用同步移交队列SynchronousQueue。空闲线程存活时间为60秒。
适用场景：适用于执行很多短期异步任务的小程序，或者是负载较轻的服务器。会根据任务量弹性地创建和回收线程。

3、newSingleThreadExecutor()

4、newScheduledThreadPool(int corePoolSize)

5、newWorkStealingPool(int parallelism) (JDK 1.8+)

虽然Executors提供的工厂方法很方便，但在生产环境中不推荐直接使用，原因如下：

newFixedThreadPool 和 newSingleThreadExecutor：它们使用的 workQueue 是默认大小为 Integer.MAX_VALUE 的 LinkedBlockingQueue（无界队列）。如果任务提交速度持续远大于任务处理速度，会导致大量任务堆积在队列中，最终耗尽内存，引发 OutOfMemoryError。
newCachedThreadPool：它允许创建的线程数量为 Integer.MAX_VALUE。如果任务数量非常多且执行时间较长，可能会导致创建大量的线程，耗尽CPU和内存资源。

核心问题：这些方法的参数是固化的，缺乏自定义性，容易导致资源耗尽的风险。

最佳实践：根据实际的业务场景（任务类型、数量、峰值等），手动直接创建 ThreadPoolExecutor 实例，以便清晰地指定核心线程数、最大线程数、队列类型和容量、拒绝策略等参数，从而做出更精细和安全的资源配置。

线程池本身不区分IO密集型还是计算密集型。池中的线程只是“工人”，它们是什么类型，完全取决于你提交给它们的“任务（Runnable/Callable）”是什么类型。

区分的重要性在于如何设置线程池参数：

计算密集型：线程数通常设置为 CPU核心数 + 1 左右。过多线程会导致频繁的CPU上下文切换，反而降低性能。
IO密集型：由于线程在执行IO操作时会阻塞，CPU空闲，因此可以设置更多的线程数，以充分利用CPU资源。通常可以设置为 CPU核心数 * (1 + 平均IO等待时间 / 平均CPU计算时间)，这个公式的估算值可能是 2 * CPU核心数 或更高，需要通过压测找到最佳值。

假设我们有一个自定义的 ThreadPoolExecutor，其执行流程是一个非常经典的状态机流程，如下图所示：

当一个新任务被提交时，线程池首先检查当前运行的线程数是否小于核心线程数（corePoolSize）。如果小于，则立即创建一个新的核心线程来执行该任务（即使其他核心线程是空闲的）。
如果当前运行的线程数已经达到或超过核心线程数，线程池会将任务尝试放入工作队列（BlockingQueue） 进行缓冲等待。
如果工作队列已满，线程池会检查当前运行的线程数是否小于最大线程数（maximumPoolSize）。如果小于，则会创建新的“非核心”线程来立即执行这个新提交的任务（而不是处理队列里的旧任务）。
如果当前线程数已经达到最大线程数，并且队列也已满，那么说明线程池已经饱和，无法处理新任务。此时会触发拒绝策略（RejectedExecutionHandler） 来处理这个被拒绝的任务。

核心原则：先扩核心线程 -> 再入队列 -> 再扩临时线程 -> 最后拒绝。

当线程池和队列都饱和时，会执行拒绝策略。JDK内置了4种策略，都实现了RejectedExecutionHandler接口：

1、ThreadPoolExecutor.AbortPolicy（默认策略）

2、ThreadPoolExecutor.CallerRunsPolicy

行为：不会丢弃任务，也不会抛出异常。而是将任务回退给调用者线程来执行。即谁（哪个线程）提交的任务，就由哪个线程自己来执行。
适用场景：这是一种负反馈机制，可以有效地降低新任务提交的速度，给线程池喘息的时间。如果任务提交方是Web服务器的处理线程，那么服务器线程将忙于执行被拒绝的任务，从而无法继续提交新任务，起到了平缓流量的作用。

3、ThreadPoolExecutor.DiscardPolicy