Java线程池的几个常见问题

1. Java自带的线程池？有哪些实现？

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

主要实现有：

1. newFixedThreadPool(int nThreads)

   • 特点

     ：创建固定大小的线程池。核心线程数 = 最大线程数 = nThreads。使用无界的LinkedBlockingQueue作为工作队列。

   • 适用场景

     ：适用于为了满足资源管理的需求，需要限制当前线程数量的场景，适用于负载较重的服务器。

2. newCachedThreadPool()

   • 特点

     ：创建一个可缓存的线程池。核心线程数为0，最大线程数为Integer.MAX_VALUE。使用同步移交队列SynchronousQueue。空闲线程存活时间为60秒。

   • 适用场景

     ：适用于执行很多短期异步任务的小程序，或者是负载较轻的服务器。会根据任务量弹性地创建和回收线程。

3. newSingleThreadExecutor()

   • 特点

     ：创建只有一个线程的线程池。核心线程数 = 最大线程数 = 1。使用无界的LinkedBlockingQueue。

   • 适用场景

     ：适用于需要保证任务顺序执行（FIFO, LIFO, 优先级）的场景。

4. newScheduledThreadPool(int corePoolSize)

   • 特点

     ：创建一个固定大小的线程池，支持定时及周期性任务执行。内部实现是ScheduledThreadPoolExecutor。

   • 适用场景

     ：需要执行延迟任务或周期性任务的场景。

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

   • 特点

     ：创建一种窃取工作的线程池。使用ForkJoinPool实现，并行度默认为CPU核心数。使用工作窃取算法，可以充分利用多核CPU的性能。

   • 适用场景

     ：非常适合会产生子任务的计算密集型任务。

---

2. 为什么不用默认实现？

虽然Executors提供的工厂方法很方便，但在生产环境中

不推荐直接使用

，原因如下：

• newFixedThreadPool 和 newSingleThreadExecutor

  ：
  它们使用的 workQueue 是默认大小为 Integer.MAX_VALUE 的 LinkedBlockingQueue（无界队列）。如果任务提交速度持续远大于任务处理速度，会导致大量任务堆积在队列中，最终耗尽内存，引发 OutOfMemoryError。

• newCachedThreadPool

  ：
  它允许创建的线程数量为 Integer.MAX_VALUE。如果任务数量非常多且执行时间较长，可能会导致创建大量的线程，耗尽CPU和内存资源。

核心问题

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

最佳实践

：
根据实际的业务场景（任务类型、数量、峰值等），

手动直接创建 ThreadPoolExecutor 实例

，以便清晰地指定核心线程数、最大线程数、队列类型和容量、拒绝策略等参数，从而做出更精细和安全的资源配置。

---

3. 线程池中的线程是IO密集型还是计算密集型？

线程池

本身不区分

IO密集型还是计算密集型。池中的线程只是“工人”，它们是什么类型，

完全取决于你提交给它们的“任务（Runnable/Callable）”是什么类型

。

• 如果你提交的任务是大量的

  网络请求、数据库操作、文件读写

  等，需要等待IO响应的，那么这些线程就是在执行

  IO密集型

  任务。
• 如果你提交的任务是大量的

  复杂算法、循环计算、数据处理

  等，主要消耗CPU资源的，那么这些线程就是在执行

  计算密集型

  任务。

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

：

• 计算密集型

  ：线程数通常设置为 CPU核心数 + 1 左右。过多线程会导致频繁的CPU上下文切换，反而降低性能。

• IO密集型

  ：由于线程在执行IO操作时会阻塞，CPU空闲，因此可以设置更多的线程数，以充分利用CPU资源。通常可以设置为 CPU核心数 * (1 + 平均IO等待时间 / 平均CPU计算时间)，这个公式的估算值可能是 2 * CPU核心数 或更高，需要通过压测找到最佳值。

---

4. 线程池执行任务的流程？

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

flowchart TD A[提交新任务 execute(runnable)] --> B{核心线程数已满?} B -- 否 --> C[创建新的核心线程执行任务] B -- 是 --> D{任务队列已满?} D -- 否 --> E[将任务加入工作队列] D -- 是 --> F{最大线程数已满?} F -- 否 --> G[创建新的临时线程执行任务] F -- 是 --> H[执行拒绝策略] E --> I[等待核心线程空闲] I --> J[从队列头部取出任务执行]

1. 当一个新任务被提交时，线程池首先检查

   当前运行的线程数是否小于核心线程数（corePoolSize）

   。如果小于，则立即创建一个新的核心线程来执行该任务（即使其他核心线程是空闲的）。
2. 如果当前运行的线程数已经达到或超过核心线程数，线程池会将任务

   尝试放入工作队列（BlockingQueue）

   进行缓冲等待。
3. 如果

   工作队列已满

   ，线程池会检查当前运行的线程数是否小于最大线程数（maximumPoolSize）。如果小于，则会创建新的“非核心”线程来立即执行这个新提交的任务（而不是处理队列里的旧任务）。
4. 如果当前线程数已经达到最大线程数，并且队列也已满，那么说明线程池已经饱和，无法处理新任务。此时会

   触发拒绝策略（RejectedExecutionHandler）

   来处理这个被拒绝的任务。

核心原则

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

---

5. 拒绝策略有哪些？

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

1. ThreadPoolExecutor.AbortPolicy（默认策略）

   • 行为

     ：直接抛出RejectedExecutionException异常。

   • 适用场景

     ：这是最严格的策略，可以确保任务不会丢失，提交任务的调用方可以捕获异常并做相应处理。

2. ThreadPoolExecutor.CallerRunsPolicy

   • 行为

     ：不会丢弃任务，也不会抛出异常。而是将任务

     回退给调用者线程

     来执行。即谁（哪个线程）提交的任务，就由哪个线程自己来执行。

   • 适用场景

     ：这是一种负反馈机制，可以有效地降低新任务提交的速度，给线程池喘息的时间。如果任务提交方是Web服务器的处理线程，那么服务器线程将忙于执行被拒绝的任务，从而无法继续提交新任务，起到了平缓流量的作用。

3. ThreadPoolExecutor.DiscardPolicy

   • 行为

     ：静默地

     直接丢弃

     无法被处理的新任务，不做任何通知，就像这个任务从来没被提交过一样。

   • 适用场景

     ：允许任务丢失的场景，不关键。

4. ThreadPoolExecutor.DiscardOldestPolicy

   • 行为

     ：丢弃

     工作队列头部

     （即下一个即将被执行的）最老的任务，然后尝试重新提交当前这个新任务。

   • 适用场景

     ：允许丢弃老任务，希望新任务有机会被执行的场景。需要注意队列中任务的优先级，防止重要的老任务被丢弃。

除了使用内置策略，你也可以实现RejectedExecutionHandler接口，自定义拒绝策略，例如将拒绝的任务持久化到磁盘或记录日志等待后续重试。

👉 点赞 | 关注 | 评论 —— 你的每一次互动，都是笔者持续创作的最大动力！
📩 想了解更多技术深度解析？点击关注按钮，订阅更新不迷路！