ThreadPoolExecutor的拒绝策略是主动控流、保障稳定的关键机制，触发条件为线程数达maximumPoolSize且工作队列已满（或池已关闭），需结合队列类型、合理参数及完备日志综合设计。
ThreadPoolExecutor 的拒绝策略不是“出问题才用”，而是线程池主动控流、保障系统稳定的关键机制。它在任务提交时被触发，核心判断依据是：当前线程数已达 maximumPoolSize 且工作队列已满（或线程池已关闭）。选对策略，比堆参数更重要。
拒绝策略触发的真实条件
很多开发者误以为“只要线程跑满就拒绝”，其实更准确的是：
- 任务先尝试加入 workQueue（如 ArrayBlockingQueue）；
- 队列满后，再尝试创建新线程，但仅当当前线程数
- 若队列已满 且 线程数已达 maximumPoolSize → 触发拒绝策略；
- 使用 SynchronousQueue（如 newCachedThreadPool）时，因容量为 0，任务无法排队，会直接走“创建线程”路径，一旦达 maxPoolSize 就立即拒绝。
四种内置策略行为与风险点
它们都实现 RejectedExecutionHandler 接口，但行为差异极大：
- AbortPolicy（默认）：抛出 RejectedExecutionException。适合需要快速暴露过载的场景，比如支付下单——宁可失败也不能错乱。但调用方必须捕获异常并处理，否则主线程中断。
- CallerRunsPolicy：让提交任务的线程（如 Web 请求线程）同步执行该任务。本质是“反压”——调用方被阻塞，自然降低提交速率。慎用于 Netty I/O 线程或 Spring MVC 的 DispatcherServlet 线程，否则整个请求链路卡死。
- DiscardPolicy：静默丢弃，不报错也不记录。适用于日志采集、埋点上报等可丢失任务，但必须配合监控（如统计丢弃数），否则问题难以发现。
- DiscardOldestPolicy：丢掉队列里最老的任务，再把新任务塞进去。适合实时性优先的场景（如行情推送），但有“丢关键任务”风险——比如刚进队列的订单可能被刚提交的监控任务挤掉。
生产环境常用组合方案
单一策略往往不够，高可靠系统通常分层应对：
立即学习“Java免费学习笔记（深入）”；
- 快慢分离：核心业务用 AbortPolicy + 熔断降级；非核心异步任务（如通知、统计）走 CallerRunsPolicy 或 DiscardPolicy；
- 缓冲兜底：将拒绝任务写入 Kafka 或 Redis List，由后台补偿消费者重试；
- 自定义复合策略：先尝试持久化，失败则降级为 DiscardPolicy，避免因 DB 故障导致全链路雪崩；
- 动态调节基础：拒绝率持续 > 1% 时，自动告警并触发线程池参数调整脚本（如扩容 maximumPoolSize 或增大队列）。
配置时容易忽略的关键细节
策略生效依赖整体设计，光换 handler 不解决问题：
- workQueue 类型决定“满”的含义：LinkedBlockingQueue 默认无界，永远不触发拒绝（除非内存溢出）；务必显式设置 capacity；
- corePoolSize 和 maximumPoolSize 差值不宜过大，否则突发流量易瞬间拉满线程，加剧拒绝；
- 拒绝日志必须包含任务标识（如 traceId、任务类型）、提交时间、线程池名称，否则无法定位问题源头；
- 测试拒绝场景不能只靠“提交超量任务”，要模拟真实负载（如线程忙于 IO、GC 频繁），否则测不出真实瓶颈。
