java线程池任务队列满了报错RejectedExecutionException怎么办？

在Java并发编程中,线程池是管理线程资源、提升系统性能与响应速度的核心工具，不当的使用或配置常常会引发一系列报错，这些问题不仅影响应用稳定性，还可能导致资源耗尽乃至系统崩溃，深入理解这些报错的根源并掌握应对策略，是每一位Java开发者必备的技能。

核心报错：RejectedExecutionException

这是线程池中最常见也最典型的异常,当开发者向线程池提交一个新任务时，线程池无法接受并执行该任务，就会抛出java.util.concurrent.RejectedExecutionException，其背后的主要原因有两个：

线程池已处于关闭状态
一旦调用了ThreadPoolExecutor的shutdown()或shutdownNow()方法，线程池就会进入关闭流程，不再接收新提交的任务，若在此之后继续提交任务，便会触发此异常，这是一种逻辑错误，通常需要通过代码审查来确保任务提交的生命周期与线程池状态一致。

线程池资源耗尽
这是更复杂也更需要关注的情况。ThreadPoolExecutor的工作逻辑可以简化为：

1. 如果核心线程数（corePoolSize）未满，则创建新线程执行任务。
2. 如果核心线程已满,则将任务放入工作队列（workQueue）。
3. 如果工作队列也满了,并且线程数未达到最大线程数（maximumPoolSize），则创建新线程执行任务。
4. 如果线程数已达到最大线程数,且工作队列也已饱和，线程池便会执行拒绝策略，默认的AbortPolicy就是抛出RejectedExecutionException。

当任务提交速度远超线程处理速度,导致队列和线程数都达到上限时，异常便会发生。

拒绝策略深度解析与选择

为了应对资源耗尽的情况,ThreadPoolExecutor提供了四种内置的拒绝策略，开发者可以根据业务需求进行选择。

策略名称	行为描述	适用场景
AbortPolicy (默认)	直接抛出RejectedExecutionException，阻止系统正常工作。	需要快速失败，让上层调用方感知到异常并进行处理，适用于对数据一致性要求高的场景。
CallerRunsPolicy	由提交任务的线程自己来执行这个被拒绝的任务。	一种温和的降级策略，可以降低任务提交速度，从而给线程池喘息的机会，但可能会阻塞调用线程。
DiscardPolicy	静默地丢弃被拒绝的任务，不做任何处理。	适用于可以容忍任务丢失的场景，如日志记录、非核心的统计上报等。
DiscardOldestPolicy	丢弃工作队列中等待时间最久的任务，然后尝试重新提交当前被拒绝的任务。	适用于希望执行新任务，且可以牺牲一部分旧任务的场景。

如果内置策略无法满足需求,还可以实现RejectedExecutionHandler接口，自定义处理逻辑，例如将任务存入磁盘、数据库或发送到消息队列进行补偿。

参数调优与最佳实践

避免线程池报错,关键在于合理的参数配置和遵循最佳实践。

合理设置核心参数

• ：通常根据CPU密集型或IO密集型任务来设定，CPU密集型可设为CPU核心数 + 1；IO密集型可设为CPU核心数 * 2。maximumPoolSize则考虑系统峰值负载。
• ：建议使用有界队列（如ArrayBlockingQueue），防止无限制堆积导致内存溢出（OutOfMemoryError），队列容量需要综合评估任务处理能力和内存限制。
• keepAliveTime：设置非核心线程的空闲存活时间，让多余的资源能够及时释放。

任务内部异常处理
一个极易被忽视的细节是：如果任务（Runnable或Callable）内部抛出未捕获的异常，该线程会终止，但线程池会悄无声息地创建一个新线程来替代它，这会掩盖问题，且线程创建开销不小，最佳实践是在任务代码的执行逻辑外包裹try-catch块，确保所有异常都被捕获和处理，而不是任其逃逸。

优雅关闭
使用shutdown()关闭线程池，它会等待已提交的任务执行完成，配合awaitTermination()可以更优雅地等待所有任务结束，避免使用shutdownNow()强制中断，除非是紧急情况。

监控与命名
为线程池设置有意义的名称前缀（通过自定义ThreadFactory），便于在日志和监控工具中定位问题，应定期监控线程池的活跃线程数、队列大小、任务完成数等关键指标，以便及时发现潜在瓶颈。

---

相关问答FAQs

问题1：我的线上应用突然出现了大量RejectedExecutionException，我应该从哪些方面着手排查？
解答： 首先不要惊慌，按照以下步骤排查：

1. 检查代码逻辑：确认是否有在调用shutdown()后仍在提交任务的逻辑错误。
2. 分析监控指标：立即查看线程池的监控面板，重点关注“活跃线程数”和“任务队列长度”，如果两者都达到了你设置的上限（maximumPoolSize和workQueue容量），则基本可以确定是资源耗尽。
3. 分析任务处理能力：深入分析提交的任务类型，是否存在因外部依赖（如数据库、第三方接口）变慢导致任务执行时间急剧增加的情况。
4. 评估流量：检查当前系统的QPS或任务提交速率是否远超设计预期。

解答： CallerRunsPolicy并非万能药，它通过“背压”机制，让任务提交者（通常是业务线程）也参与到任务执行中，从而降低任务提交速度，给线程池处理任务的时间，这在一定程度上可以缓解问题，但它的缺点是，如果任务提交速度持续过高，会导致大量的业务线程被阻塞在执行任务上，反而可能影响整个应用的吞吐量和响应性，甚至导致应用级“假死”，它适用于那些可以接受一定延迟、且调用方线程资源相对充足的场景，对于要求高响应性的系统，可能需要结合其他限流、熔断机制，或者选择更激进的DiscardPolicy。