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使用的线程池，拒绝策略默认不可配，必须显式定义ThreadPoolTaskExecutorbean并设setRejectedExecutionHandler
四种内置拒绝策略怎么选，别硬套文档描述
每种策略对应不同业务语义，不是“哪个更高级就用哪个”。选错比不处理还危险。
-
AbortPolicy（默认）：适合强一致性场景，比如支付扣款任务，宁可失败也不能丢；但必须配套监控告警，否则异常被吞就等于静默失败 -
CallerRunsPolicy：让提交任务的线程自己执行该任务。能缓解压力，但会拖慢调用方——如果调用方是Web请求线程，会导致HTTP响应变慢甚至超时 -
DiscardPolicy：静默丢弃。适合日志上报、埋点等“丢了也不影响主流程”的任务；但要注意丢弃无提示，得靠业务层加唯一ID+幂等校验兜底 -
DiscardOldestPolicy：丢队列头的任务，腾位置给新任务。只适用于任务有明显时效性（如实时行情推送），且老任务价值低于新任务
自定义拒绝策略里最容易漏掉的两件事
写个RejectedExecutionHandler实现不难，但线上出问题往往卡在这两个细节上：
立即学习“Java免费学习笔记（深入）”；
- 别在
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。
