线程池拒绝策略中AbortPolicy疑问？

Question

AbortPolicy，当请求线程数超出最大线程数，就会抛出RejectExecutionException。我想请问，多线程环境下，这种情况不是很多的吗，毕竟你没法提前知道到底需要多少线程。如果每次都抛异常程序还怎么正常运行呢？

Answer 1

所以还有CallerRunsPolicy

---

CallerRunsPolicy（调用者运行策略）

• 功能：当触发拒绝策略时，只要线程池没有关闭，就由提交任务的当前线程处理。
• 使用场景：一般在不允许失败的、对性能要求不高、并发量较小的场景下使用，因为线程池一般情况下不会关闭，也就是提交的任务一定会被运行，但是由于是调用者线程自己执行的，当多次提交任务时，就会阻塞后续任务执行，性能和效率自然就慢了。

AbortPolicy（中止策略）

• 功能：当触发拒绝策略时，直接抛出拒绝执行的异常，中止策略的意思也就是打断当前执行流程
• 使用场景：这个就没有特殊的场景了，但是一点要正确处理抛出的异常。

DiscardPolicy（丢弃策略）

• 功能：直接静悄悄的丢弃这个任务，不触发任何动作
• 使用场景：如果你提交的任务无关紧要，你就可以使用它 。因为它就是个空实现，会悄无声息的吞噬你的的任务。所以这个策略基本上不用了

DiscardOldestPolicy（弃老策略）

• 功能：如果线程池未关闭，就弹出队列头部的元素，然后尝试执行
• 使用场景：这个策略还是会丢弃任务，丢弃时也是毫无声息，但是特点是丢弃的是老的未执行的任务，而且是待执行优先级较高的任务。基于这个特性，我能想到的场景就是，发布消息，和修改消息，当消息发布出去后，还未执行，此时更新的消息又来了，这个时候未执行的消息的版本比现在提交的消息版本要低就可以被丢弃了。因为队列中还有可能存在消息版本更低的消息会排队执行，所以在真正处理消息的时候一定要做好消息的版本比较。

---

参考: https://cloud.tencent.com/dev...

Answer 2

这个说的不是很准确，它在达到核心线程以后，就会去queue堆积数据，而不是直接创建非核心线程，所以你合理的线程池参数，甚至于压根就不会触发拒绝策略，或者你作死用无界队列，这都不会触发拒绝策略
如果实在是瞬间queue直接被堆积完并且立刻达到了最大线程，你所有任务又必须执行，可以自己实现拒绝策略，采用阻塞加入队列的方式，这样只是会阻塞，上面那哥们也把jdk的几种默认实现给说了