选abortpolicy还是callerrunspolicy取决于任务是否可丢、系统是否可停、上游是否能扛失败：abortpolicy快失败，适合可重试的rpc/http请求；callerrunspolicy慢执行，适合不可丢但可延迟的日志/埋点任务。
选 AbortPolicy 还是 CallerRunsPolicy，关键看你的任务能不能丢、系统能不能停、上游能不能扛住失败。
AbortPolicy：要的是“快失败”，不是“不处理”
它直接抛 RejectedExecutionException，不兜底、不妥协。这不是缺陷，而是设计意图——让问题立刻暴露。
- 适合上游具备重试能力的场景，比如 RPC 异步回调、HTTP 短查询请求，失败后可立即重发或降级
- 配合监控告警使用效果最好：一旦触发，说明线程池已彻底饱和，必须人工介入扩容或限流
- 不适合日志写入、指标聚合等后台任务——丢了会导致数据断层，业务不可见但实际受损
CallerRunsPolicy：用“慢下来”换“不丢任务”
被拒任务交回给提交线程（比如 Web 请求线程）去执行。这会自然拖慢调用方节奏，相当于把压力反向传导回去。
- 适合不能丢、但可以延迟的任务，例如审计日志落盘、用户行为埋点汇总
- 对吞吐敏感、对延迟容忍度较高的后台作业很友好，避免 OOM 或雪崩式拒绝
- 慎用于高频入口（如 Controller 层），否则可能拖垮整个请求线程，引发级联超时
DiscardPolicy 和 DiscardOldestPolicy：静默丢弃必须有底线
这两个策略不抛异常，容易掩盖风险。用之前得确认“丢得安心”。
- DiscardPolicy 彻底静默，连日志都不打——只建议用于采样类任务，比如每千次请求抽1次做性能分析
- DiscardOldestPolicy 会踢掉队列里最老的任务再重试提交当前任务，但可能反复挤掉同一任务，破坏公平性，慎用于有顺序依赖的场景
自定义策略：兜底要讲逻辑，不是加个日志就完事
常见做法包括记录日志+告警、异步重试、降级写入消息队列、甚至触发熔断开关。
- 日志记录必须带上下文（如任务类型、提交时间、线程池状态），否则排查无从下手
- 重试需设上限和退避策略，避免二次压垮
- 写入 Kafka/RocketMQ 是常见兜底方式，但要注意消息可靠性与消费延迟
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
