【JAVA-面经】2.为什么不建议使用 Execuators 来创建线程池

沐七小殿下

于 2024-09-18 21:07:57 发布

阅读量258

点赞数 4

分类专栏： JAVA 文章标签： java 开发语言

本文链接：https://blog.csdn.net/qq_27128467/article/details/142343833

版权

JAVA 专栏收录该内容

9 篇文章 1 订阅

订阅专栏

在 Java 中，虽然 Executors 提供了便捷的方法来创建线程池，但不建议直接使用 Executors 创建线程池是因为它的一些默认配置可能会导致隐患，尤其是在高并发或长时间运行的应用程序中。以下是主要原因：

1. `Executors.newFixedThreadPool()` 和 `Executors.newSingleThreadExecutor()` 存在 OOM（内存溢出）风险

这两个方法返回的线程池使用的是 无界的任务队列（LinkedBlockingQueue），这意味着如果提交的任务数量超过了线程池的处理能力，任务会不断堆积在队列中，而不会被拒绝。
这可能导致内存消耗无限增长，最终导致 OutOfMemoryError。
解决方案：可以显式地定义队列的最大长度，或在构造线程池时指定合适的拒绝策略。

2. `Executors.newCachedThreadPool()` 存在线程数量无限增长风险

newCachedThreadPool() 创建的线程池没有核心线程数限制，只有在线程空闲 60 秒后才会回收。这意味着在高并发场景中，可能会创建非常多的线程，导致系统资源耗尽。
这种线程池适用于短期并发较大的任务处理，但在长时间、高并发任务场景中，线程数可能会增长到不可控的状态，最终耗尽 CPU 或内存资源。
解决方案：显式设置最大线程数量或限制任务提交频率。

3. 缺乏对线程池配置的灵活控制

Executors 创建的线程池使用了默认的配置，开发者没有太多机会自定义线程池的策略。例如：
- 核心线程数和最大线程数的设置。
- 队列的类型和长度。
- 拒绝策略（当任务无法提交时如何处理）。
使用 ThreadPoolExecutor 可以完全自定义线程池的这些参数，从而更好地控制线程池的行为。

4. 拒绝策略不可控

Executors 创建的线程池使用了默认的拒绝策略 AbortPolicy（抛出 RejectedExecutionException）。在实际场景中，可能希望使用其他拒绝策略，例如：
- CallerRunsPolicy：由调用线程执行任务。
- DiscardPolicy：丢弃任务但不抛异常。
- DiscardOldestPolicy：丢弃最旧的任务，尝试提交新的任务。

5. 不符合最佳实践（Java 官方文档建议）

Java 官方文档和阿里巴巴《Java 开发手册》等都建议直接使用 ThreadPoolExecutor，并且明确指定线程池的参数配置，而不是依赖 Executors 的默认配置。

推荐使用 `ThreadPoolExecutor` 直接创建线程池

与其使用 Executors 的快捷方法，推荐直接通过 ThreadPoolExecutor 来创建线程池，并显式配置参数。

示例：

import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class Main {
    public static void main(String[] args) {
        ThreadPoolExecutor threadPool = new ThreadPoolExecutor(
            5,  // 核心线程数
            10,  // 最大线程数
            60L,  // 空闲线程等待时间
            TimeUnit.SECONDS,  // 时间单位
            new LinkedBlockingQueue<>(100),  // 阻塞队列大小
            new ThreadPoolExecutor.CallerRunsPolicy()  // 拒绝策略
        );

        // 提交任务
        for (int i = 0; i < 200; i++) {
            threadPool.execute(() -> System.out.println("Task executed by: " + Thread.currentThread().getName()));
        }

        // 关闭线程池
        threadPool.shutdown();
    }
}