-
目录
📘 前言
最近自己动手实操一个数据分析平台项目（BI 系统），主要参考了鱼皮老师的视频课程（编程导航 - 程序员一站式编程学习交流社区，做您编程学习路上的导航员），从零开始搭建了整个后端架构。
其实我之前也看过这些课程视频，但只是“看”，并没有真正动手实践。这次是第一次真正从头撸一个完整的项目，很多知识点只有亲自实践过，才会真正理解其中的原理和坑点。
在开发过程中，遇到了一个需求：用户上传数据后，系统需要异步生成图表。为了避免主线程阻塞、提升性能，我引入了线程池来处理这类耗时任务。在具体实现中，我使用了 ThreadPoolExecutor，查阅了大量资料，深入学习了它的使用原理和各项参数配置，花了一上午时间调试与踩坑。
最终，不仅把线程池成功整合进了项目，还顺便补上了之前一直不够扎实的并发编程基础。为了避免遗忘，也方便以后复用，特此整理这篇笔记，希望也能对您有所帮助！
🌟 顺带一提：像我这种之前没自己实操过完整项目的，真的很推荐鱼皮老师的课程。内容系统且贴合实战，特别适合我们这种正在从“会看代码”向“能写项目”转变的开发者。我不是水军！！如果您也还没真正动手实操过项目，真的可以去看看我记得有三天免费可以看看视频，觉得不合适可以再退。
📚 ThreadPoolExecutor 简介
ThreadPoolExecutor 是 Java 并发包中最核心的线程池实现类，它提供了对线程池行为的精细控制。相比 Executors.newFixedThreadPool() 等静态方法，直接使用 ThreadPoolExecutor 构造函数可以避免资源耗尽风险（如 OOM）并具备更高的可控性。
⭐ 为什么不推荐使用内置线程池（Executors 静态工厂方法）？
在《阿里巴巴Java开发手册》“并发处理”章节中，明确指出：
线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。
原因如下：
-
使用线程池的好处
线程池能减少线程创建和销毁的开销，降低系统资源消耗，避免系统因为创建大量线程导致内存耗尽或线程切换过于频繁的问题。 -
禁止使用 Executors 创建线程池
直接调用Executors的静态工厂方法（如newFixedThreadPool、newCachedThreadPool等）会使用无界队列或固定大小线程池，容易引起资源耗尽或性能瓶颈。 -
推荐使用 ThreadPoolExecutor 构造函数
明确指定核心线程数、最大线程数、队列类型和容量、拒绝策略，能让开发者清晰了解线程
🔍 核心构造参数详解
public ThreadPoolExecutor( int corePoolSize,
int maximumPoolSize,
long keepAliveTime, TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory, RejectedExecutionHandler handler)| 参数名 | 说明 |
|---|---|
| corePoolSize | 核心线程数，线程池中始终保留的线程数，即使空闲也不会销毁。新任务进来时，若当前运行线程数小于 corePoolSize，会新建线程执行。 |
| maximumPoolSize | 最大线程数，当任务过多且任务队列已满时，线程池可以临时扩展到此线程数来处理任务。超过后会触发拒绝策略。 |
| keepAliveTime | 非核心线程的最大空闲时间，超过该时间的非核心线程将被回收。默认核心线程不会回收，除非开启 allowCoreThreadTimeOut(true)。 |
| unit | keepAliveTime 的时间单位，如 TimeUnit.SECONDS、TimeUnit.MILLISECONDS 等。 |
| workQueue | 任务队列，用来缓存等待执行的任务。推荐使用有界队列（如 ArrayBlockingQueue）避免内存溢出风险。 |
| threadFactory | 线程工厂，负责创建线程。可自定义线程名，便于排查问题和日志跟踪。 |
| handler | 拒绝策略，当线程池达到最大线程数且任务队列已满时执行的策略。默认是 AbortPolicy，直接抛异常。可自定义将任务持久化到数据库等。 |
⚙️ 任务执行流程详解
-
如果当前运行线程数小于核心线程数 corePoolSize，线程池会新建线程立即执行新任务。
-
如果当前线程数达到 corePoolSize，新任务将被放入任务队列中等待执行。
-
如果任务队列满了，但当前线程数小于最大线程数 maximumPoolSize，线程池会新建非核心线程处理任务。
-
如果当前线程数达到最大线程数，且任务队列已满，则执行拒绝策略（RejectedExecutionHandler）。
🧮 线程数配置建议：CPU密集型 vs IO密集
| 任务类型 | 建议核心线程数配置 | 说明 |
|---|---|---|
| CPU密集型任务 | 核心线程数 = CPU 核心数 + 1 | 适用于复杂计算、加密等高 CPU 使用场景，避免线程切换开销过大。 |
| IO密集型任务 | 核心线程数 = 2 × CPU 核心数 | 适用于网络请求、文件读写等等待操作较多的场景，可提升 CPU 利用率。 |
备注：
CPU 核心数可通过系统任务管理器等工具查看。
根据实际负载和任务特点，可适当调整线程数，避免线程过多导致资源竞争。
IO 密集型线程数设置较多时，注意系统的线程调度和内存消耗情况。
🛠️ 实战参数建议配置
以下是我在实际项目中针对 IO 密集型异步图表生成任务调优后的线程池配置示例：
ThreadPoolExecutor executor = new ThreadPoolExecutor(
16, // 核心线程数（2N）
16, // 最大线程数（不再扩容）
60L, TimeUnit.SECONDS, // 非核心线程60秒无任务自动销毁
new ArrayBlockingQueue<>(60), // 队列容量60，防止OOM
threadFactory, // 你的自定义线程工厂
new ChartRejectedExecutionHandler(chartMapper) // 自定义拒绝策略
);💾 自定义拒绝策略 —— 拒绝任务持久化到数据库
在 ThreadPoolExecutor 中，当线程池达到最大线程数且任务队列已满时，默认会执行 AbortPolicy 拒绝策略，即直接抛出异常。虽然简单，但这种做法存在明显缺陷：
-
可能导致重要任务丢失，影响业务稳定性。
-
系统异常时，无法保证所有任务被妥善处理。
为提升系统健壮性和任务可靠执行，我在项目中引入了自定义拒绝策略，具体做法是：
-
拒绝的任务不直接丢弃，改为持久化存入数据库，并标记为“等待执行”状态。
-
通过后台定时调度或手动触发，可从数据库中加载延迟任务，补偿执行。
-
有效缓解线程池瞬时压力，避免任务因流量峰值丢失或异常。
这种自定义拒绝策略相当于一种“软拒绝”，利用持久化机制确保任务最终能够完成，显著提升了系统的容错能力和稳定性。
当然，具体实现时需结合项目业务设计合适的数据库表结构、字段及状态标识，确保数据完整且便于后续调度和管理。
🎉 心得总结
在这次项目中，我通过异步执行任务结合自定义拒绝策略，真正掌握了 ThreadPoolExecutor 的设计原理和使用技巧。相比以往直接使用 Executors.newFixedThreadPool()，现在我能够从核心线程数、最大线程数、任务队列容量以及拒绝策略等多个维度进行合理调优，有效避免了任务因线程池满载被拒绝丢失的问题。
这次实践不仅让我对线程池的原理和参数配置有了深入理解，也提升了我构建高可用、高性能后台系统的能力。
希望您在阅读这篇文章后，能对线程池的使用和调优有所启发，也能在自己的项目中更加自信地应用这些知识，实现更稳定和高效的并发任务处理。祝您开发愉快！
扫一扫
8364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
