面试官问：线程池拒绝策略怎么选，才不会丢任务？

面试官问：线程池拒绝策略怎么选，才不会丢任务？本文将从原理、策略选型到高阶方案，助你从容应对。

面试官问：线程池拒绝策略怎么选，才不会丢任务？

当面试官追问“线程池满了如何处理？哪种策略能不丢任务？”时，仅回答“用CallerRunsPolicy”往往不够。面试官真正考察的是结合业务场景选型和规避任务丢失风险的能力。本文将从原理、策略选型到高阶方案，助你从容应对。

一、拒绝策略触发条件剖析

拒绝策略生效的本质是任务提交速率超出线程池处理能力，需同时满足：

核心线程满载：所有corePoolSize线程均处于忙碌状态。
队列饱和：任务队列（如LinkedBlockingQueue）容量耗尽。
线程数达上限：线程总数已达maximumPoolSize，无法创建新线程。

场景示例

电商秒杀场景，线程池配置corePoolSize=5,maximumPoolSize=10, 队列容量capacity=20。若瞬时涌入 50 个下单任务：

5 个核心线程处理任务。
20 个任务进入队列。
创建 5 个非核心线程处理新任务。
剩余 10 个任务触发拒绝策略。策略选择不当，轻则任务丢失（下单失败），重则系统崩溃。

二、JDK 原生拒绝策略详解

JDK 提供 4 种策略（实现RejectedExecutionHandler），其任务保障性各异：

1. AbortPolicy (默认策略)：抛异常，任务必丢

逻辑：直接抛出RejectedExecutionException，任务不执行。

ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 10, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(20), new ThreadPoolExecutor.AbortPolicy() );

适用：需立即感知任务丢失的场景（如金融转账）。任务丢失即业务异常。
风险：未捕获异常导致提交线程崩溃；捕获不处理仍丢任务。

2. DiscardPolicy：静默丢弃，隐患最大

逻辑：直接丢弃新任务，无任何通知。
代码：

ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 10, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(20), new ThreadPoolExecutor.DiscardPolicy() );

适用：几乎无推荐场景！仅适用于日志记录等非核心且可容忍丢失的任务。
风险：任务“凭空消失”，排查困难。

3. DiscardOldestPolicy：弃旧保新

逻辑：丢弃队列头部（最老）任务，尝试将新任务入队。
代码：

ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 10, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(20), new ThreadPoolExecutor.DiscardOldestPolicy() );

适用：新任务优先级高于旧任务的场景（如实时数据统计）。
风险：丢弃的是已入队的任务，若为关键业务（如订单创建），将导致异常。

4. CallerRunsPolicy：提交线程执行，不丢任务！

逻辑：由提交任务的线程（如 Tomcat 工作线程）直接执行被提任务。
代码：

ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 10, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(20), new ThreadPoolExecutor.CallerRunsPolicy() );

适用：核心且不容丢失的任务（秒杀下单、用户注册）。
优势：
- 零丢失：提交线程不崩溃，任务必执行。
- 天然限流：提交线程忙于执行任务，减缓新任务提交速度。
风险：若提交线程是关键路径（如主线程），执行任务会阻塞其本职工作（如处理其他请求）。

三、高阶方案：自定义策略解决痛点

原生策略存在丢任务或阻塞风险，实践中常采用自定义策略：

1. 方案一：MQ 异步重试（绝对保任务）

逻辑：拒绝时，将任务序列化后发送至消息队列（RabbitMQ/RocketMQ/Kafka）。消费者异步拉取并重试提交，直至成功或记录失败。
代码示例：

// 自定义拒绝策略：MQ 重试 RejectedExecutionHandler mqRejectionHandler = (Runnable runnable, Executor executor) -> { try { String taskJson = JSON.toJSONString(runnable); // 序列化任务 rabbitTemplate.convertAndSend(「thread-pool-retry-queue」, taskJson); log.info(「任务入 MQ 重试：{}」, taskJson); } catch (Exception e) { // MQ 失败降级：CallerRunsPolicy new ThreadPoolExecutor.CallerRunsPolicy().rejectedExecution(runnable, executor); log.error(「任务入 MQ 失败，降级处理」, e); } }; // 配置线程池 ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 10, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue<>(20), mqRejectionHandler // 使用自定义策略 ); // MQ 消费者（示例） @RabbitListener(queues = 「thread-pool-retry-queue」) public void handleRetryTask(String taskJson) { Runnable task = JSON.parseObject(taskJson, Runnable.class); for (int i = 0; i < 3; i++) { // 重试 3 次 if (executor.getQueue().remainingCapacity() > 0) { executor.submit(task); log.info(「任务重试成功：{}」, taskJson); return; } try { TimeUnit.SECONDS.sleep(1); // 间隔 1 秒 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } log.error(「任务重试失败，记录到 DB：{}」, taskJson); // 记录失败 dbService.saveFailedTask(taskJson); }

适用：绝对不容丢失的核心业务（支付、转账、库存扣减）。
优势：零丢失风险，不阻塞提交线程，大厂核心业务首选。

2. 方案二：动态扩容（减少拒绝触发）

逻辑：拒绝前尝试动态扩容队列或最大线程数（在预设上限内）。扩容失败则降级（如CallerRunsPolicy）。
代码示例（可扩容队列）：

class ResizableBlockingQueue<E> extends LinkedBlockingQueue<E> { private int maxCapacity; // 最大扩容上限 public ResizableBlockingQueue(int initialCapacity, int maxCapacity) { super(initialCapacity); this.maxCapacity = maxCapacity; } public boolean expandCapacity(int newCapacity) { if (newCapacity > maxCapacity) return false; // ... 实现扩容逻辑 (需考虑线程安全) return true; } @Override public boolean offer(E e) { if (super.remainingCapacity() == 0) { // 队列满 int newCapacity = (int) (size() * 1.2); // 尝试扩容 20% if (expandCapacity(newCapacity)) { log.info(「队列扩容至：{}」, newCapacity); } } return super.offer(e); } } // 自定义拒绝策略：先扩容，后降级 RejectedExecutionHandler expandRejectionHandler = (runnable, executor) -> { ThreadPoolExecutor pool = (ThreadPoolExecutor) executor; ResizableBlockingQueue<?> queue = (ResizableBlockingQueue<?>) pool.getQueue(); // 1. 尝试扩容队列 if (queue.expandCapacity((int) (queue.size() * 1.2))) { pool.submit(runnable); return; } // 2. 尝试扩容最大线程数 (上限假设为 20) if (pool.getMaximumPoolSize() < 20) { pool.setMaximumPoolSize(pool.getMaximumPoolSize() + 2); pool.submit(runnable); return; } // 3. 扩容失败，降级 CallerRunsPolicy new ThreadPoolExecutor.CallerRunsPolicy().rejectedExecution(runnable, executor); }; // 配置线程池 ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 10, 60L, TimeUnit.SECONDS, new ResizableBlockingQueue<>(20, 100), // 初始容量 20，最大扩容至 100 expandRejectionHandler // 使用自定义策略 );

适用：流量波动较大的场景（如大促预热到峰值过渡期）。
优势：减少拒绝触发频率，平衡性能与稳定性。

四、面试高频考点与应对

CallerRunsPolicy阻塞提交线程如何规避？
判断提交线程性质（如是否为 Tomcat 工作线程），是则改用 MQ 策略。
为任务执行添加超时控制（Future.get(timeout)），避免长期阻塞。
MQ 重试如何避免任务重复执行？
幂等设计是关键：任务携带唯一标识（如订单 ID）。
执行前检查标识状态（查 DB/Redis），已执行则跳过。
示例：下单任务用订单 ID 查 Redis 键order:123:executed。
除拒绝策略外，如何避免丢任务？
参数调优：corePoolSize= 峰值 QPS / 单线程 QPS；queueCapacity= 峰值时长 * 单线程 QPS。
预热核心线程：executor.prestartAllCoreThreads()。
提交前检查：若executor.getQueue().remainingCapacity() < 阈值，提前返回“系统繁忙”。

五、总结：选型与避坑指南

选型：
- 核心业务保任务 →MQ 重试策略。
- 非核心实时场景保新 →DiscardOldestPolicy。
- 简单场景不阻塞核心线程 →CallerRunsPolicy。
- 避免使用AbortPolicy/DiscardPolicy。
避坑：
- CallerRunsPolicy→ 警惕阻塞核心线程。
- MQ 重试 → 必须实现幂等。
- 动态扩容 → 设定资源上限。
核心原则：拒绝策略是兜底，优化参数（核心线程数、队列容量）和源头控流（提交前检查）才是根本。