线程池任务过载处理策略

ThreadPoolExecutor的拒绝策略并非简单“线程池满就触发”，而是仅在有界队列已满且线程数达到maximumPoolSize后、新任务提交时才生效，其行为高度依赖队列类型（如ArrayBlockingQueue可控，LinkedBlockingQueue几乎不触发）、提交方式（execute()/submit()均有效）、执行上下文（拒绝逻辑运行在调用线程，切忌阻塞操作）及可观测性设计；四大内置策略各具适用场景——AbortPolicy强调强实时但需调用方兜底，CallerRunsPolicy可缓解压力却可能拖慢业务响应，DiscardPolicy和DiscardOldestPolicy分别适合容忍丢失或需保活最新任务的场景，而真正落地的关键在于将队列水位、活跃线程数与拒绝计数三者联动监控，并通过原子计数、降频打点和指标暴露（如Micrometer/Prometheus）实现过载可感知、可诊断、可优化。

ThreadPoolExecutor 拒绝策略触发的典型场景

拒绝策略只在任务提交时触发，不是线程池满就立刻执行，而是当 workQueue 也满了、且线程数已达 maximumPoolSize 后，再提交新任务才会走拒绝逻辑。常见误判是看到 CPU 或线程忙就以为触发了拒绝，其实可能只是任务在队列里排队——得确认 getQueue().size() 和 getActiveCount() 才能定位。

• 队列类型影响极大：LinkedBlockingQueue 默认无界，几乎不触发拒绝；ArrayBlockingQueue 有界才可控
• 提交用 execute() 才会触发拒绝策略；submit() 底层也调用 execute()，同样生效
• 拒绝发生在主线程（提交者线程），不是工作线程，所以策略里的操作不能太重，否则拖慢提交方

四种内置拒绝策略的行为差异

AbortPolicy（默认）：直接抛 RejectedExecutionException，适合强实时系统，但需调用方显式捕获处理。

CallerRunsPolicy：由提交任务的线程自己执行该任务。能缓解压力，但可能让业务线程卡住，尤其在高并发 HTTP 请求场景下，导致请求响应变慢甚至超时。

DiscardPolicy：静默丢弃，不报错也不执行。适合日志采集等允许丢失的场景，但难以监控是否真丢了任务。

DiscardOldestPolicy：丢掉队列头的任务，再尝试重新提交当前任务。前提是队列支持 poll()（如 ArrayBlockingQueue），对 PriorityBlockingQueue 可能丢错优先级任务。

自定义拒绝策略要注意线程安全和可观测性

自定义策略本质是实现 RejectedExecutionHandler 接口，但容易忽略两点：

• 策略方法 rejectedExecution(Runnable r, ThreadPoolExecutor executor) 在提交线程中运行，若在里面做日志聚合、发告警、写磁盘等操作，会阻塞所有后续提交
• 缺少计数器或埋点，导致过载发生时无法区分是突发流量还是配置不合理。建议搭配 AtomicLong 记录丢弃次数，并通过 Micrometer 或 Prometheus 暴露指标

public class LoggingRejectHandler implements RejectedExecutionHandler {
    private final AtomicLong rejectedCount = new AtomicLong();
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
        long count = rejectedCount.incrementAndGet();
        if (count % 100 == 0) { // 降频打点
            System.err.println("Task rejected, total: " + count);
        }
        // 不做耗时操作：不 sleep、不 IO、不锁大对象
    }
}

配置拒绝策略前必须检查队列容量与核心参数匹配

很多人设了 DiscardPolicy 却发现任务照常执行——其实是队列没满。关键检查点：

• 确认构造时传的是有界队列：new ArrayBlockingQueue<>(100)，而非 new LinkedBlockingQueue<>()
• corePoolSize 和 maximumPoolSize 的关系影响扩容时机；若两者相等，队列满后立刻触发拒绝，没有“新建线程”缓冲
• 使用 allowCoreThreadTimeOut(true) 时，即使 corePoolSize > 0，空闲核心线程也会被回收，实际并发能力可能低于预期

真正难的不是选哪个策略，而是把「队列水位」「活跃线程数」「拒绝计数」三者关联起来看趋势。单独调一个参数，往往掩盖了真实瓶颈。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《线程池任务过载处理策略》文章吧，也可关注golang学习网公众号了解相关技术文章。