线上任务“凭空蒸发”主因是拒绝策略配置失当与日志缺失，须立即补上三件事：所有execute/submit调用需try-catch捕获rejectedexecutionexception；catch中记录含任务类型、业务id等的结构化日志；同步打点监控并触发告警。
线上任务“凭空蒸发”，往往不是代码没跑，而是被线程池悄悄拒之门外，且连日志都没留下——这是典型的拒绝策略配置失当 + 日志缺失双重故障。核心问题不在“是否拒绝”，而在于“拒绝了但没人知道”。解决的关键是让每次拒绝都可感知、可追溯、可干预。
必须立即补上的三件事
无论当前用的是哪种拒绝策略，以下动作缺一不可：
- 所有 execute/submit 调用必须包裹 try-catch，捕获 RejectedExecutionException，不能依赖上层兜底；
- 在 catch 块中记录结构化日志，至少包含：任务类型、业务 ID（如 order_id / trace_id）、提交时间、线程池名称、队列当前长度、活跃线程数；
- 同步打点监控指标，例如 metrics.counter("threadpool.rejected", "policy=abort", "pool=payment").increment()，确保告警能自动触发。
默认 AbortPolicy 的致命盲区
AbortPolicy 是 JDK 默认策略，但它不输出任何日志，只抛异常。如果调用方没 catch，异常会向上冒泡——在 Web 场景中可能变成 500 错误，在定时任务中可能静默吞掉整个 job。更危险的是，很多人只加了 catch，却漏掉了 log 和打点，导致事故复盘时只能看到“某段时间请求变少”，完全无法定位是线程池在丢任务。
建议：生产环境禁用裸 AbortPolicy。如需快速失败，应使用包装后的版本，例如：
new ThreadPoolExecutor.AbortPolicy() {@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
log.warn("ABORT: task rejected by {}, queueSize={}, activeCount={}",
e.getThreadPoolName(), e.getQueue().size(), e.getActiveCount());
super.rejectedExecution(r, e);
}
}
慎用 CallerRunsPolicy 的隐藏代价
它看似“不丢任务”，实则把压力转嫁给调用线程。若调用方是 Tomcat 的 worker 线程，一个被拒任务就会拖慢整个 HTTP 请求，造成响应延迟飙升甚至超时。此时监控显示“上游慢”，根因却是下游线程池策略不当。
若必须用 CallerRunsPolicy，请配套做两件事：
- 在执行前加 executor.isShutdown() 预检，避免 shutdown 后还往里塞任务；
- 对任务执行耗时设硬性上限（如用 Future.get(200, MILLISECONDS) 包裹），超时即主动放弃，防止调用线程被长期阻塞。
用自定义策略堵住静默丢失漏洞
DiscardPolicy 和 DiscardOldestPolicy 都不打日志，属于“真·静音丢弃”。线上绝不能直接使用。推荐落地一个轻量级自定义策略：
- 记录被拒任务的简要上下文（如类名 + hashCode + 关键参数 toString）；
- 异步写入本地 ring buffer 或发到日志中间件（避免 IO 阻塞主线程）；
- 当 1 分钟内拒绝超 5 次，自动触发告警（而非等大盘阈值）。
这样既不增加主路径开销，又能让每次拒绝都留下线索，真正实现“任务可丢，痕迹不丢”。
