Executors功能如此强大，ThreadPoolExecutor功不可没（一）

关注

原创最新推荐文章于 2026-10-14 11:00:26 发布 1.1k 阅读 AI 写同款· GEO 优化 ›

Android线程池全面解析：Executors工厂方法与阿里规约的深层思考文章摘要： Android开发中合理使用线程池对应用性能至关重要。Executors提供的四种线程池（FixedThreadPool、CachedThreadPool、SingleThreadExecutor和ScheduledThreadPool）各有特点，但都暗藏风险：无界队列可能导致OOM，无限创建线程会耗尽资源。阿里Java规约建议手动创建线程池，通过控制核心参数（线程数、队列容量、拒绝策略）规避风险。最佳实践包括：使用有界队列、限制最大线程数、自定义线程工厂、选择合适的拒绝策略（如CallerRu 阅读详情

作为 Java 程序员，无论是技术面试、项目研发或者是学习框架源码，不彻底掌握 Java 多线程的知识，做不到心中有数，干啥都没底气，尤其是技术深究时往往略显发憷。

在 JDK1.5 以前，研发人员在面对线程频繁调度的场景，必须手动打造线程池，来节约系统开销（画外音：真是吃了不少苦头）。

从 JDK1.5 开始，Java 提供了一个 Excutors 工厂类来生产线程池，可以帮助研发人员有效的进行线程控制（画外音：不用造轮子啦，爽歪歪）。

（配图释义：JDK 1.8 能用 Excutors 创建的线程池）

如上图示意，Excutors 提供了满足各种场景的线程池创建方式， Java 研发人员就不用苦逼哈哈的去造轮子啦，谁用谁爽。

但是，阿里开发规约明确强制研发人员：线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式。

（配图释义：阿里巴巴Java开发手册，线程池创建规约）

不过，若经常关注源码的同学会发现，无论是 newFixedThreadPool() 方法、newSingleThreadExecutor() 方法，还是 newCachedThreadPool() 方法，其背后均使用了 ThreadPoolExecutor。

（配图释义：JDK 1.8 能用 Excutors 创建的线程池的背后）

通过上面源码截图，可以清晰看出，以上几种创建线程池的方式，均是对 ThreadPoolExecutor 类的封装，所以要想彻底掌握线程池，势必要吃透线程池背后的 ThreadPoolExecutor。

解剖：构造函数

有关 ThreadPoolExecute 构造函数，很多书上或者文章都会提到，下面再简单了解一下每个参数的具体含义。

public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler)

构造函数的参数释义：

corePoolSize：指定线程池中的线程数量；

maximumPoolSize：指定线程池中的最大线程数量；

keepAliveTime：当线程池中线程数量超过 corePoolSize 时，空闲线程的存活时间；

unit：keepAliveTime 的单位；

workQueue：任务队列，存放提交尚未被执行的任务；

threadFactory：线程工厂，用于创建线程，一般用默认的即可；

handler：拒绝策略，当任务太多来不及处理，如何拒绝任务。

以上参数除了 workQueue 以及 handler 外，大部分都很易懂。接下来重点说说 workQueue 以及 handler 两个参数。

参数 BlockingQueue<Runnable> workQueue，是用于存放提交尚未被执行的任务的队列，类型是 BlockingQueue 接口的对象，用于存放 Runnable 对象。

参数 RejectedExecutionHandler handler 是指当任务数量超过系统承载能力时，该如何处理？其中 JDK 提供了四种拒绝策略。

（配图释义：JDK 1.8 内置的拒绝策略）

JDK 提供的四种拒绝策略归纳，简单了解一下。

思考：使用 Executors 会导致 OOM？

了解完 ThreadPoolExecutor 类的构造函数，接下来探讨一下阿里开发手册明确强制的一条使用线程池的规约。

为了更清晰的认识，不妨走进源码看一看。首先走进 newFixedThreadPool() 方法的源码，一探究竟。

如源码截图所示，newFixedThreadPool() 方法的实现，返回一个 corePoolSize 和 maximumPoolSize 大小一样的，并且使用了 LinkedBlockingQueue 任务队列的线程池。

如上面 LinkedBlockingQueue 的源码所示，队列的默认长度为 Integer.MAX_VALUE，那么当任务提交频繁时，线程池中的线程处理不过来时，队列可能会迅速膨胀，从而会出现 OOM。

接着走进 newSingleThreadExecutor() 方法的源码，看看有没有新大陆。

如源码截图示意，newSingleThreadExecutor 方法实现中，corePoolSize 和 maximumPoolSize 设置的值均为 1，返回一个单线程的线程池，并且使用 LinkedBlockingQueue 任务队列来存在提交的任务，与 newFixedThreadPool() 方法一样，当任务提交频繁时，线程池中的线程处理不过来时，队列会迅速膨胀，从而会出现 OOM。

最后看看 newCachedThreadPool() 方法的源码实现，一探究竟。