java线程池拒绝策略是资源耗尽时的主动决策点，仅在核心线程满、队列满、最大线程数达上限且线程池运行中四条件同时满足时生效；abortpolicy默认抛异常需兜底，callerrunspolicy由调用线程执行实现反压，discardpolicy静默丢弃适合采样任务，discardoldestpolicy丢弃最老任务保新数据。
Java线程池的拒绝策略不是“出错了”，而是资源耗尽时的主动决策点。它只在线程池运行中、核心线程已满、工作队列已满、最大线程数已达上限这四个条件同时满足时才生效。选对策略，等于为系统加了一道可控的“压力泄洪阀”。
AbortPolicy：默认但需主动兜底
这是 ThreadPoolExecutor 的默认策略，行为简单粗暴：直接抛出 RejectedExecutionException。它不隐藏问题，而是把压力立刻反馈给调用方。
- 适合关键路径任务，比如支付确认、库存扣减——失败必须被感知，不能静默丢弃
- 必须配合 try-catch 使用，否则异常会向上冒泡中断业务流程
- 建议在 catch 块中记录完整日志（含任务类型、线程池状态）、上报监控指标、触发告警
- 注意：抛异常本身开销低，但若上游未处理，可能引发雪崩
CallerRunsPolicy：自带反压的保底执行
当任务被拒绝时，由提交任务的线程（即调用 execute() 的线程）同步执行该任务。这不是重试，而是把压力“还回去”。
- 任务不会丢失，适合日志采集、异步通知等“可延迟但不可丢”的场景
- 天然具备反压效果：调用线程被阻塞，自然降低任务提交速率，缓解下游压力
- 不适合高吞吐或实时性敏感场景，因为主线程可能被长时间占用
- 若调用线程是 Web 容器线程（如 Tomcat 的 worker 线程），可能影响请求响应
DiscardPolicy：零成本静默丢弃
什么也不做，直接丢弃被拒绝的任务。没有日志、不抛异常、不执行任何逻辑。
- 开销最低，适合对丢失不敏感的采样类任务，例如每秒心跳上报、埋点统计
- 不能用于有状态或关键业务任务，否则故障难以定位
- 生产环境慎用，至少应搭配监控看板观察拒绝率是否持续升高
- 常与限流组件（如 Sentinel、Resilience4j）配合使用，形成“限流 + 丢弃”组合
DiscardOldestPolicy：丢最老的，腾位置给新的
尝试从工作队列头部移除一个最早入队的任务，再尝试重新提交当前被拒绝的任务。
- 适用于希望“保新弃旧”的场景，比如实时行情推送、消息轮询——新数据比旧数据更有价值
- 仅对支持
poll()和offer()的队列有效（如ArrayBlockingQueue、LinkedBlockingQueue） - 注意：若队列为空或移除失败，仍会走默认拒绝逻辑；且移除操作本身有轻微并发开销
- 不适用于需要严格 FIFO 或任务顺序不可变的业务
四种策略没有绝对优劣，关键看任务语义和系统韧性目标。AbortPolicy 强制你正视过载，CallerRunsPolicy 给你缓冲时间，DiscardPolicy 追求极致吞吐，DiscardOldestPolicy 则做了取舍判断。真正复杂的是自定义策略——它不该是补丁，而应是可观测、可降级、解耦设计的一环。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
