线程池拒绝任务是正常流控行为，发生在workQueue已满且线程数达maximumPoolSize时，由所选拒绝策略决定处理方式；默认AbortPolicy抛异常，CallerRunsPolicy交由调用线程执行，DiscardPolicy静默丢弃，DiscardOldestPolicy丢弃队列头任务后重试，自定义策略需解决记录与补偿问题，避免递归提交、阻塞操作及线程安全漏洞。
为什么线程池会拒绝任务
当线程池的 workQueue 已满，且线程数已达 maximumPoolSize，新提交的任务就无法被接纳，此时触发拒绝策略。这不是异常，而是线程池的正常流控行为——关键在于你选的策略是否匹配业务语义。
常见误判是把 RejectedExecutionException 当作 bug，其实它只是信号：系统负载超设计水位，该由策略决定“怎么丢”或“要不要重试”。
四种内置拒绝策略的实际差异
Java 提供的四个 RejectedExecutionHandler 实现，行为和适用场景差别很大，不能只看名字：
-
AbortPolicy（默认）：抛出RejectedExecutionException，适合不允许丢失、必须立刻感知失败的场景，比如支付回调校验 -
CallerRunsPolicy：由提交任务的线程（即调用execute()的线程）直接执行该任务，会降低提交速度，但能缓解压力，适合突发流量可接受延迟的后台任务 -
DiscardPolicy：静默丢弃，不报错也不执行，适合日志采集、监控埋点等允许丢失的非关键任务 -
DiscardOldestPolicy：丢弃队列头任务（最老的），再尝试重新提交当前任务，适合任务有实效性、新任务比旧任务重要的场景（如实时行情推送）
自定义拒绝策略要注意什么
自定义策略不是写个 if-else 就完事，核心要解决两个问题：是否记录、是否补偿。
立即学习“Java免费学习笔记（深入）”；
