拒绝策略配置不当是系统稳定性的直接威胁，需根据任务类型选择DiscardPolicy、AbortPolicy或DiscardOldestPolicy，禁用CallerRunsPolicy，并配套监控、轻量日志与可开关的自定义策略。
拒绝策略配置不当不是小问题，而是系统稳定性的直接威胁。它不总在高并发时才暴露，往往在流量平稳期悄然积累隐患，直到某次扩容、发布或偶发抖动时集中爆发。
支付类任务用DiscardPolicy，等于主动丢钱
订单创建、资金扣减这类强一致性操作，一旦被静默丢弃，用户感知就是“点了没反应”或“重复下单”。DiscardPolicy不会抛异常，上层完全无感，错误日志里连一条记录都没有。
- AbortPolicy是更安全的选择——它强制抛出
RejectedExecutionException，让Controller或Service层能捕获并转入死信队列或数据库暂存，后续可重试 - 绝不能配CallerRunsPolicy——让Tomcat线程去执行支付逻辑，会拖慢整个HTTP请求链路，可能引发线程池雪崩
- 别靠加大队列撑过峰值——ArrayBlockingQueue设成10000，内存吃紧、GC飙升，反而让服务更脆弱
日志上报配AbortPolicy，接口动不动500
用户行为日志、埋点数据丢失一条不影响主流程，但AbortPolicy会让每个提交都可能冒泡出异常，若没在submit侧统一try-catch，就会变成HTTP 500，污染核心接口成功率指标。
- DiscardPolicy更适合这类场景：零开销丢弃，不打断主线程
- 必须配套监控：每分钟拒绝数突增超过50次，就该触发告警，说明采集链路已严重承压
- 加轻量日志即可：只记“[log-pool] rejected: 23 times @ 2026-06-16T01:45”，不记任务内容，避免IO成为瓶颈
实时任务误用CallerRunsPolicy，响应延迟翻倍
设备心跳、风控规则匹配、告警推送等任务，价值随时间快速衰减。让调用方线程（比如Netty EventLoop）去同步执行被拒任务，不仅无法提升吞吐，还会把延迟从毫秒级拉到秒级。
立即学习“Java免费学习笔记（深入）”；
- DiscardOldestPolicy更合适：主动踢掉队列里最老的心跳包，腾出空间给最新数据
- 注意队列类型匹配：用ArrayBlockingQueue时，容量要按峰值QPS×平均处理时长预估，避免扩容失败反复触发拒绝
- 禁用CallerRunsPolicy——这类任务本身无状态、轻量，没必要让调用方兜底执行
生产环境还在用默认AbortPolicy，等于裸奔
默认策略只抛异常，不做任何记录或降级，相当于把问题甩给上层框架。Web容器收到未捕获的RejectedExecutionException，直接返回500；异步任务则彻底消失，连traceID都找不到。
- 自定义策略至少包含三件事：记录拒绝时间+任务简要标识、触发降级逻辑（如转同步执行或缓存暂存）、内置限频（防止日志刷爆磁盘）
- 拒绝不是故障终点，而是可观测入口——每次拒绝都应该生成一条监控指标和一条结构化日志
- 策略本身要可开关：灰度期可先开启日志记录，确认影响范围后再启用降级动作
