Java线程池拒绝策略详解与自定义方法

本文深入解析了Java线程池中至关重要的拒绝策略机制，重点围绕`RejectedExecutionHandler`接口展开——它并非“备用开关”，而是在工作队列满且线程数已达最大值时的最后防线；文章不仅厘清了四种内置策略（Abort、CallerRuns、Discard、DiscardOldest）的本质差异与致命陷阱，更手把手教你如何编写安全、健壮、可观测的自定义拒绝处理器：从防御性空值检查、资源预注入、异常兜底记录，到规避死递归和性能瓶颈，覆盖开发、测试、上线全链路实践要点，特别适合高并发日志、埋点、限流降级等非核心但高频出问题的场景，帮你真正把“任务被拒”从线上黑盒变成可控、可溯、可运维的关键能力。

RejectedExecutionHandler 是什么，什么时候会被触发

它不是线程池的“备用开关”，而是拒绝策略的兜底接口——当 ThreadPoolExecutor 的工作队列已满、且线程数已达 maximumPoolSize，再提交新任务时，就会调用它。

常见错误现象：RejectedExecutionException 并非总出现；如果你用了 CallerRunsPolicy 或自定义实现，异常可能被吞掉，但实际逻辑已降级（比如本该异步处理的任务变成同步阻塞调用者）。

典型使用场景：

• 高并发写日志、上报埋点等非核心路径，允许丢弃或延迟处理
• 下游服务限流，需主动降级而非压垮自身
• 任务具备幂等性，可转存到 DB/消息队列重试

怎么写一个安全可用的自定义 RejectedExecutionHandler

别直接 new 接口实现类——必须确保内部逻辑不抛未捕获异常，否则会静默吞掉拒绝事件，连日志都看不到。

实操建议：

• 构造函数里传入 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 或采样输出。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java线程池拒绝策略详解与自定义方法》文章吧，也可关注golang学习网公众号了解相关技术文章。