Java线程池自定义拒绝策略需构建可落地、可重试、可观测的逃生通道：用有界队列和合理maximumPoolSize确保策略触发，将任务转存MQ/DB/本地磁盘，避开递归提交、无超时、日志爆炸等陷阱，并配套监控告警验证实效。
Java 线程池自定义拒绝策略防止高并发下任务丢失，关键不是“写个接口”，而是构建一条**可落地、可重试、可观测**的任务逃生通道。它必须在真正触发拒绝时（队列满 + 线程已达 maximumPoolSize）接管任务，而不是等系统崩溃后再补救。
先确保拒绝策略真能被触发
很多任务“看似丢失”，其实是拒绝策略根本没生效——因为配置了无界队列（如默认的 LinkedBlockingQueue），任务无限堆积，最终 OOM 而非触发拒绝。要让策略起作用，必须：
- 用有界队列：如 ArrayBlockingQueue(200) 或容量为 0 的 SynchronousQueue；
- 明确设置 maximumPoolSize（不能和 corePoolSize 相同却忽略它）；
- 监控两个指标：executor.getQueue().size() 和 executor.getActiveCount()，比只看拒绝数更早发现问题。
不丢任务的核心：把拒绝任务转存到可靠介质
任务不能留在内存里等下次提交，必须落盘或发往外部系统。常见且生产可用的方式有：
- 发往消息队列（推荐）：将 Runnable 序列化为 JSON 或封装成可序列化对象（含 traceId、参数快照、重试次数），异步发送至 Kafka/RocketMQ；消费者端需实现幂等与延迟重试逻辑；
-
写入数据库：建一张
rejected_tasks表，字段包括 id、task_data、retry_count、status、create_time；由定时任务扫描 status=WAITING 的记录并重新 submit； -
本地磁盘暂存（降级兜底）：MQ 不可用时，将任务写入按时间戳命名的 JSON 文件（如
/tmp/rejected_202608201015.json），后续通过脚本或服务恢复；注意加文件锁和清理机制。
实现时必须避开的致命陷阱
自定义策略代码看似简单，但几处错误会导致雪崩或静默丢任务：
立即学习“Java免费学习笔记（深入）”；
- 禁止在 rejectedExecution 中调用 executor.execute() 或 submit()：可能递归触发拒绝，甚至死锁；
- 补偿操作必须带超时与降级：比如 MQ 发送设 3 秒超时，失败后 fallback 到本地磁盘，而不是吞掉异常；
-
日志必须限流：高频拒绝时只打关键字段（如 task ID、类型、时间），避免
e.printStackTrace()打爆 I/O； - 不要依赖 ThreadLocal 或 TransmittableThreadLocal 传递上下文：拒绝发生在线程池内部，调用线程可能已退出，上下文早已失效。
搭配监控与告警才真正防丢
策略写了不等于任务保住了，得知道它是否在工作：
- 对每次拒绝执行打点：如
metrics.counter("threadpool.rejected", "type", "pay_callback").increment()； - 记录被拒任务的关键字段（ID、业务类型、提交时间、traceId），接入 ELK 或 Grafana；
- 配置告警：当 1 分钟内拒绝数 > 50 或连续 5 分钟 > 10，立刻通知；
- 定期抽检落库/落 MQ 的任务是否被正常消费，验证端到端链路。
