线程池拒绝任务的直接原因是无法新建线程且工作队列已满，由拒绝策略主动响应；判断流程为：先尝试用空闲线程执行，再尝试入队，最后在达到最大线程数且队列满时触发拒绝。
Java线程池拒绝任务，不是因为“线程不够用”这么简单，而是当线程池已无法继续接纳新任务时，由其内置的拒绝策略（RejectedExecutionHandler）主动做出的响应。核心触发条件只有一个：任务提交时，线程池既不能新建线程（已达最大线程数），也无法将任务放入工作队列（队列已满或为无界但线程数已达上限）。
线程池拒绝任务的真实判断流程
提交任务（execute()）后，线程池按固定顺序尝试处理：
- 如果当前线程数 corePoolSize），直接创建新核心线程执行任务；
- 否则，尝试将任务加入工作队列（
workQueue.offer()）； - 如果入队失败（例如队列已满、或队列是同步队列
SynchronousQueue且无空闲线程可立即交接），则尝试创建非核心线程（但不超过maximumPoolSize）； - 如果此时线程数已达
maximumPoolSize，且队列已无法接收任务——拒绝发生。
常见导致拒绝的典型场景
不同队列类型 + 参数组合，会显著影响拒绝时机：
-
使用有界队列（如
ArrayBlockingQueue）+ 线程数打满：任务持续涌入，队列填满后，所有新增任务都会被拒绝； -
使用
SynchronousQueue（实际容量为0）：它不缓存任务，必须有空闲线程立刻接手；若没有，就直接触发拒绝——这是“预设即拒绝”的典型设计； - 核心线程数=最大线程数=1，队列容量=0：相当于单线程串行执行，第二个任务提交即被拒绝；
-
线程池被
shutdown()或shutdownNow()后还提交任务：此时线程池状态为SHUTDOWN或STOP，不再接受新任务，直接拒绝。
四种内置拒绝策略的行为差异
拒绝策略不是异常，而是对“无法处理的任务”的处置方式，选错可能掩盖问题：
立即学习“Java免费学习笔记（深入）”；
-
AbortPolicy（默认）：抛出RejectedExecutionException，调用方需捕获并处理； -
CallerRunsPolicy：让提交任务的线程自己执行该任务（适用于希望减缓提交速度的场景）； -
DiscardPolicy：静默丢弃，不通知，容易丢失任务且难以排查； -
DiscardOldestPolicy：丢弃队列头部任务，再尝试重新提交当前任务（注意：仅对支持poll()的队列有效）。
如何避免误触发拒绝？关键看参数协同
拒绝本身不是Bug，而是系统过载的信号。合理配置才能让它真正发挥保护作用：
- 不要盲目设置极大容量的有界队列（如10万），这会让拒绝延迟发生，导致OOM风险转移至堆内存；
- 使用
SynchronousQueue时，务必确保maximumPoolSize足够支撑峰值并发，否则拒绝会非常频繁； - 监控指标比“是否拒绝”更重要：关注队列长度、活跃线程数、拒绝计数（可通过自定义
ThreadPoolExecutor子类或包装器暴露）； - 业务上敏感的任务，不应依赖默认拒绝策略，建议包装后记录日志、降级或异步重试。
拒绝策略不是故障，而是线程池在资源边界内保持稳定运行的守门机制。理解它何时触发、为何触发，才能让线程池真正成为可控、可观、可运维的组件。
