💡 写在前面

在 Java 高并发编程中，线程池不仅是提升系统吞吐量的“利器”，更是面试中的“常客”。然而，很多同学在实战中经常遇到任务丢失、系统 OOM 或是线程数配不准的问题。

今天，我们就来彻底拆解 ThreadPoolExecutor 的底层逻辑，并看看它如何与 CompletableFuture 优雅配合！

---

一、 七大核心参数：决定线程池的“性格” 🛠️

创建一个线程池时，我们需要配置 7 个参数。理解它们之间的动态关系比死记硬背更重要：

1️⃣corePoolSize (核心线程数)：

线程池里的“正式员工”。即使空闲也不会被解雇。

2️⃣maximumPoolSize (最大线程数)：

线程池的“极限产能”。当队列满了且正式员工忙不过来时，才会招募“临时工”。

4️⃣keepAliveTime & unit (存活时间)：

“临时工”闲下来后多久被裁减。

5️⃣workQueue (任务队列)：

• 存放等待执行任务的缓冲区。

⚠️ 避坑： 慎用 LinkedBlockingQueue 的无参构造（默认长度 $2^{31}-1$），极易导致 OOM！建议使用有界队列 ArrayBlockingQueue。

6️⃣threadFactory (线程工厂)：

• 强烈建议自定义！ 给线程起个好名字（如 order-pool-%d），线上排查堆栈信息时，你会感谢现在的自己。

7️⃣handler (拒绝策略)：

当池子和队列都塞满时的“兜底方案”。

• AbortPolicy: 抛出异常（默认）。

• CallerRunsPolicy: 谁提交任务，谁负责执行（能起到天然的限流作用）。

• DiscardPolicy / DiscardOldestPolicy: 静默丢弃任务（慎用）。

---

二、 深度解析：为什么说 CallerRunsPolicy 是最安全的策略？🛡️

在四种内置拒绝策略中，CallerRunsPolicy（调用者运行策略）通常是后台业务的首选。

为什么它最“稳”？

• 任务零丢失：任务不会被抛弃或报错，而是回退给提交任务的线程（调用者）亲自执行。

• 天然背压（Backpressure）：当线程池处理不过来时，调用者线程被占用了，自然就没法继续提交新任务，从而在源头上实现了限流，给线程池喘息的机会。

• 优雅降级：系统在高压下只是变慢了（响应延迟增加），但不会崩溃，保证了业务的最终一致性。

---

三、 线程池增长策略：别再记错了！📉

很多开发者以为是“核心线程 ➡️最大线程 ➡️ 队列”，这是大错特错的！

标准执行流程：

1. Step 1: 核心线程未满 ➡️ 直接创建核心线程执行。

2. Step 2: 核心线程已满 ➡️ 进入任务队列等待。

3. Step 3: 队列已满 ➡️ 创建非核心线程（临时工）直到达到 maximumPoolSize。

4. Step 4: 全部满载 ➡️ 触发 RejectedExecutionHandler 拒绝策略。

---

四、 实战：CompletableFuture 怎么用线程池？🔥

CompletableFuture 默认使用 ForkJoinPool.commonPool()，它是全局共享的。如果你的业务中有耗时 IO 任务，千万不要用默认池，否则会拖垮整个应用的异步响应！

💻 正确姿势：

Java

// 1. 手动创建业务隔离的线程池
ThreadPoolExecutor bizExecutor = new ThreadPoolExecutor(
    8, 
    16, 
    60L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(500),
    new ThreadFactoryBuilder().setNameFormat("biz-async-%d").build(), // 需引入Guava或自定义
    new ThreadPoolExecutor.CallerRunsPolicy() // 最安全的兜底
);

// 2. 异步调用时显式传入线程池
CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    log.info("执行耗时业务逻辑...");
    return "Done";
}, bizExecutor); // 👈 关键：指定专用池

// 3. 后续回调也建议指定线程池
future.thenAcceptAsync(res -> {
    log.info("处理回调结果: {}", res);
}, bizExecutor);

---

五、 总结与建议 📝

• 参数配置：CPU 密集型设置 $N+1$，IO 密集型建议 $2N$ 起步，并根据压测调整。

• 资源隔离：不同的业务模块（如：发邮件、算薪资、查库存）建议使用不同的线程池，互不干扰。

• 监控：建议定时输出线程池的 getActiveCount() 和 getQueue().size()，提前发现潜在风险。

---

🚀 Powered by Moshow 郑锴 | 🌟 Might the holy code be with you !

👉 公众号「软件开发大百科」 | CSDN传送门：https://zhengkai.blog.csdn.net/

---

最后： 你在生产环境中遇到过线程池相关的 CPU 飙升或者 OOM 吗？欢迎在评论区分享你的填坑经历！👇