优雅兜底需构建有状态、可恢复、不阻塞机制：仅在线程池关闭、活跃线程达maximumPoolSize、工作队列满三者同时成立时触发拒绝策略；推荐自定义持久化策略，异步序列化关键字段入库，失败则降级至内存队列或本地磁盘；须配套独立重试服务、幂等性设计与可观测性接入。
要让线程池在超载时把任务“优雅”转入持久化存储或降级处理，关键不是简单替换拒绝策略，而是构建一套有状态、可恢复、不阻塞的兜底机制。核心在于：拒绝发生时，不丢任务、不卡主线程、不依赖内存缓存。
明确触发条件再设计策略
拒绝策略只在以下任一条件满足时触发：
- 线程池已关闭（调用 shutdown/shutdownNow 后）
- 活跃线程数已达 maximumPoolSize
- 工作队列（如 ArrayBlockingQueue）已满且无法入队
只有在这三者同时成立时，rejectedExecution() 才会被调用。因此，策略设计必须基于这个确定性时机，而不是靠“猜测队列是否快满”提前干预。
自定义持久化拒绝策略（推荐主用）
实现 RejectedExecutionHandler 接口，将任务序列化后写入外部存储，确保进程重启后仍可恢复：
立即学习“Java免费学习笔记（深入）”；
- 任务数据建议只存关键字段（如业务ID、参数JSON），避免直接序列化 Runnable 实例（可能含不可序列化对象）
- 使用异步方式写库（如 CompletableFuture.runAsync + 数据库连接池），防止阻塞提交线程
- 记录 retryCount 和 status 字段，支持幂等重试和失败归档
- 写库失败时，退回到本地内存队列（如 ConcurrentLinkedQueue）暂存，并启动后台线程轮询重试
复合策略应对多级降级场景
单一策略难以覆盖所有异常路径，可组合使用：
- 先尝试 CallerRunsPolicy：若调用线程未被阻塞（如非 Web 请求线程），可立即执行，实现自然限流
- 若执行失败或调用线程不适合执行（如 Tomcat 的 NIO 线程），再交由自定义持久化策略接管
- 最终兜底：持久化也失败时，写入本地磁盘文件（如 JSON 行格式），避免完全丢失
这种分层处理既保留了 CallerRunsPolicy 的轻量降级能力，又通过持久化保证了任务最终可达性。
配套必须做的三件事
光有拒绝策略不够，还需配套机制才能真正“优雅”：
- 独立重试服务：单独部署定时任务或消息监听器，扫描数据库中 status = 'WAITING' 的任务，重新 submit 到线程池
- 幂等性设计：任务执行前校验唯一业务键（如订单号+操作类型），避免重复处理
- 可观测性接入：在 rejectedExecution 中上报 metrics（如 reject_count、persist_fail_rate）并记录结构化日志，便于告警和溯源
不复杂但容易忽略：持久化后的任务，一定要有明确的生命周期管理——成功后更新 status，失败达阈值后转入死信表或通知人工介入。
