ThreadPoolExecutor饱和时，有哪些拒绝策略可以应对？

本文共计4284个文字，预计阅读时间需要18分钟。

`ThreadPoolExecutor` 的拒绝策略，也就是我们常说的拒绝策略，主要是用来处理当线程池无法处理新提交的任务时的应对措施。它本质上是一种拒绝策略，主要有以下四种标准实现：

解决方案

当线程池的任务队列已满，并且线程池中的线程数量也达到了最大限制（

maximumPoolSize）时，新的任务就会被拒绝。这时，

ThreadPoolExecutor会根据预设的拒绝策略来处理这些“无处安放”的任务。

1. AbortPolicy (默认策略) 这是最直接也最暴力的做法。当任务被拒绝时，它会直接抛出一个

RejectedExecutionException运行时异常。这意味着，如果你的代码没有捕获这个异常，程序很可能会因此中断。我个人觉得，在很多场景下，如果你的系统对任务丢失零容忍，并且希望立即发现问题，这个策略是首选。它会抛出异常，这往往意味着你的系统负载已经超出了设计容量，需要介入处理。它强制你关注并解决潜在的容量问题，是一种“快速失败”的机制。

2. CallerRunsPolicy 这个策略就显得“负责任”多了，它不会直接拒绝任务，而是让提交任务的线程（也就是调用

execute()方法的那个线程）自己去执行这个任务。初看起来，这好像是个不错的折中方案，既不丢任务，也不直接报错。但细想一下，它其实是在向调用者施压，迫使调用者等待，这可能会导致整个系统的吞吐量下降，甚至产生连锁反应。我用过几次，发现它在处理瞬时高峰时表现不错，能起到一定的背压（backpressure）作用，防止系统被冲垮。但如果负载持续高企，反而会拖慢整个应用，因为提交任务的线程也被占用了，无法继续提交新任务。