线程池拒绝任务是正常流控行为，发生在workQueue已满且线程数达maximumPoolSize时，由所选拒绝策略决定处理方式；默认AbortPolicy抛异常，CallerRunsPolicy交由调用线程执行，DiscardPolicy静默丢弃，DiscardOldestPolicy丢弃队列头任务后重试，自定义策略需解决记录与补偿问题，避免递归提交、阻塞操作及线程安全漏洞。
为什么线程池会拒绝任务
当线程池的 workQueue 已满，且线程数已达 maximumPoolSize，新提交的任务就无法被接纳，此时触发拒绝策略。这不是异常，而是线程池的正常流控行为——关键在于你选的策略是否匹配业务语义。
常见误判是把 RejectedExecutionException 当作 bug，其实它只是信号：系统负载超设计水位，该由策略决定“怎么丢”或“要不要重试”。
四种内置拒绝策略的实际差异
Java 提供的四个 RejectedExecutionHandler 实现，行为和适用场景差别很大，不能只看名字：
-
AbortPolicy（默认）：抛出RejectedExecutionException，适合不允许丢失、必须立刻感知失败的场景，比如支付回调校验 -
CallerRunsPolicy：由提交任务的线程（即调用execute()的线程）直接执行该任务，会降低提交速度，但能缓解压力，适合突发流量可接受延迟的后台任务 -
DiscardPolicy：静默丢弃，不报错也不执行，适合日志采集、监控埋点等允许丢失的非关键任务 -
DiscardOldestPolicy：丢弃队列头任务（最老的），再尝试重新提交当前任务，适合任务有实效性、新任务比旧任务重要的场景（如实时行情推送）
自定义拒绝策略要注意什么
自定义策略不是写个 if-else 就完事，核心要解决两个问题：是否记录、是否补偿。
立即学习“Java免费学习笔记（深入）”；
例如记录到日志并异步落库归档，或把任务转存到 Kafka 重试队列：
public class LoggingRejectHandler implements RejectedExecutionHandler {
private final Logger logger = LoggerFactory.getLogger(LoggingRejectHandler.class);
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
logger.warn("Task rejected: {}, pool size: {}, queue size: {}",
r.getClass().getSimpleName(),
executor.getPoolSize(),
executor.getQueue().size());
// 注意：这里不能再调用 executor.execute(r)，否则可能死循环
// 如需补偿，应走独立通道，比如发送 MQ 消息
}
}
容易踩的坑：
- 在拒绝处理逻辑里再次调用
executor.execute()，导致无限递归或堆栈溢出 - 同步写磁盘或远程调用，拖慢拒绝处理本身，反而加剧线程池阻塞
- 忽略线程安全：多个线程同时触发拒绝时，共享资源（如计数器）未加锁或未用
AtomicInteger
如何验证拒绝策略真正在起作用
光看代码没用，得让线程池“真的满一次”。推荐用最小可复现配置压测：
- 设
corePoolSize = 1，maximumPoolSize = 1，LinkedBlockingQueue容量为1 - 连续提交 3 个休眠任务（如
Thread.sleep(1000)），第三个必被拒绝 - 观察日志或捕获异常，确认触发的是你设置的策略，而不是默认的
AbortPolicy
特别注意：用 Executors.newFixedThreadPool(n) 创建的池，其队列是无界 LinkedBlockingQueue，永远不触发拒绝——这是线上最常被忽略的陷阱。
