Java中的RejectedExecutionException处理_线程池满负载时的拒绝策略

文章小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《Java中的RejectedExecutionException处理_线程池满负载时的拒绝策略》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

RejectedExecutionException是线程池的背压信号，表明任务队列已满且线程全忙，需结合pool size、active threads、queued tasks定位根因，而非盲目调大参数。

为什么RejectedExecutionException总在高并发时突然冒出来

这不是线程池“坏了”，而是它明确告诉你：任务队列已满、核心/最大线程全在跑、新任务没地方塞了。默认策略是AbortPolicy，直接抛RejectedExecutionException——它不藏问题，只是把背压暴露给你。

常见错误现象：java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@12345678 rejected from java.util.concurrent.ThreadPoolExecutor@87654321[Running, pool size = 10, active threads = 10, queued tasks = 100, completed tasks = 1234]。关键看最后三组数字：pool size、active threads、queued tasks——如果后两者都顶到上限，就是真满了。

• 别急着调大corePoolSize或queueCapacity，先确认是不是任务本身执行过慢（比如数据库慢查、外部HTTP超时），导致线程被长期占住
• 用executor.getActiveCount()和executor.getQueue().size()在线上做轻量监控，比日志更早发现问题
• Spring Boot中通过@Async使用的线程池，拒绝策略默认不可配，必须显式定义ThreadPoolTaskExecutor bean并设setRejectedExecutionHandler

四种内置拒绝策略怎么选，别硬套文档描述

每种策略对应不同业务语义，不是“哪个更高级就用哪个”。选错比不处理还危险。

• AbortPolicy（默认）：适合强一致性场景，比如支付扣款任务，宁可失败也不能丢；但必须配套监控告警，否则异常被吞就等于静默失败
• CallerRunsPolicy：让提交任务的线程自己执行该任务。能缓解压力，但会拖慢调用方——如果调用方是Web请求线程，会导致HTTP响应变慢甚至超时
• DiscardPolicy：静默丢弃。适合日志上报、埋点等“丢了也不影响主流程”的任务；但要注意丢弃无提示，得靠业务层加唯一ID+幂等校验兜底
• DiscardOldestPolicy：丢队列头的任务，腾位置给新任务。只适用于任务有明显时效性（如实时行情推送），且老任务价值低于新任务

自定义拒绝策略里最容易漏掉的两件事

写个RejectedExecutionHandler实现不难，但线上出问题往往卡在这两个细节上：

• 别在rejectedExecution方法里做耗时操作（如发HTTP、写DB），它运行在提交线程上下文中，会阻塞任务提交者；最多记日志 + 发MQ消息异步处理
• 务必检查Runnable是否实现了Future或含回调逻辑——有些框架封装的任务对象（如CompletableFuture任务）被丢弃后，上游可能永远等不到结果，造成悬挂
• 如果用Lombok的@Data或@ToString打日志，小心循环引用导致GC压力或日志卡死；建议只打印task.getClass().getSimpleName()和关键字段

线程池配置和拒绝策略必须一起看

单独调优拒绝策略没意义。真正起作用的是三者联动：corePoolSize、maximumPoolSize、队列类型及容量。

• 用LinkedBlockingQueue且不限容量？那maximumPoolSize完全无效，所有任务都会进队列，永远触发不了拒绝策略——除非内存OOM
• 用ArrayBlockingQueue限容100，但maximumPoolSize设成200？线程数冲到200前，队列就满了，大量任务在低并发时就被拒绝
• 推荐组合：SynchronousQueue + maximumPoolSize > corePoolSize，这样能快速扩容，拒绝只发生在真正资源耗尽时；但要确保keepAliveTime足够短，避免空闲线程堆积

复杂点在于：拒绝不是故障终点，而是系统反馈信号。你得顺着它去查是下游慢、流量突增、还是任务设计本身不合理。光换策略不查根因，下次还在同一行代码抛出同一个RejectedExecutionException。

终于介绍完啦！小伙伴们，这篇关于《Java中的RejectedExecutionException处理_线程池满负载时的拒绝策略》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！