rejectedexecutionhandler 是线程池拒绝策略的兜底接口，当工作队列满且线程数达 maximumpoolsize 时触发；常见于高并发日志、埋点等非核心路径，需自定义安全实现并验证生效。
RejectedExecutionHandler 是什么，什么时候会被触发
它不是线程池的“备用开关”，而是拒绝策略的兜底接口——当 ThreadPoolExecutor 的工作队列已满、且线程数已达 maximumPoolSize，再提交新任务时，就会调用它。
常见错误现象：RejectedExecutionException 并非总出现；如果你用了 CallerRunsPolicy 或自定义实现，异常可能被吞掉，但实际逻辑已降级（比如本该异步处理的任务变成同步阻塞调用者）。
典型使用场景：
- 高并发写日志、上报埋点等非核心路径，允许丢弃或延迟处理
- 下游服务限流，需主动降级而非压垮自身
- 任务具备幂等性，可转存到 DB/消息队列重试
怎么写一个安全可用的自定义 RejectedExecutionHandler
别直接 new 接口实现类——必须确保内部逻辑不抛未捕获异常，否则会静默吞掉拒绝事件，连日志都看不到。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 构造函数里传入
Logger或ScheduledExecutorService，避免在rejectedExecution方法里临时创建资源 - 方法体内第一行加
if (r == null || executor == null) return;，防止 NPE（某些极端情况下r或executor为 null） - 不要在其中调用
executor.submit(...)再次提交——可能再次触发拒绝，形成死递归 - 若要落库或发消息，务必包裹 try-catch，并记录原始异常堆栈（
e.printStackTrace()不要出现在生产代码里）
示例片段：
public class LoggingRejectHandler implements RejectedExecutionHandler {
private final Logger log = LoggerFactory.getLogger(LoggingRejectHandler.class);
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
if (r == null || executor == null) return;
String msg = String.format("Task %s rejected from %s", r, executor);
log.warn(msg);
// 可选：把 r 序列化后写入本地文件或 Kafka，注意别阻塞
}
}
四种内置策略的区别和踩坑点
它们不是“功能差异”，而是对「谁来承担拒绝成本」的分工选择：
-
AbortPolicy：抛RejectedExecutionException，适合强一致性场景，但上游没 catch 就会崩 -
CallerRunsPolicy：让提交线程自己执行任务——看似“不丢”，实则可能拖慢调用方（比如 HTTP 请求线程被卡住），导致整体吞吐暴跌 -
DiscardPolicy：静默丢弃，无日志，线上几乎无法排查为何任务消失 -
DiscardOldestPolicy：丢队列头的任务，再尝试 submit——如果队列是PriorityBlockingQueue，可能误删高优先级任务
参数差异关键点：所有策略都不感知任务类型或上下文，所以无法区分“这个任务丢了影响大不大”。想做到这点，必须自定义。
上线前必须验证的三件事
很多问题只在压测或流量突增时暴露：
- 确认你的 handler 被真正生效：检查
ThreadPoolExecutor构造时传入的是你自己的实例，而不是默认的AbortPolicy - 模拟拒绝场景做单元测试：手动 set core/max pool size 为 1，queue capacity 为 0，submit 2 个 sleep 任务，看 handler 是否被调用
- 观察 GC 和线程状态：如果 handler 里做了对象序列化+缓存，又没控制大小，可能引发频繁 GC 或 OOM
最常被忽略的是：handler 执行耗时。哪怕只是打一行 log，如果每秒拒绝上千次，log 框架的锁竞争也可能成为瓶颈。真要打日志，考虑异步 appender 或采样输出。
