Java线程池拒绝策略是什么

本篇内容介绍了"Java线程池拒绝策略是什么"的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

一、CallerRunsPolicy(调用者运行策略)

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

二、AbortPolicy(中止策略)

当触发拒绝策略时，它就会直接抛出拒绝执行的异常，中止策略就是直接打断当前执行的流程。它没有特殊的使用场景，但是一点要正确处理抛出的异常。ThreadPoolExecutor中默认的策略就是AbortPolicy，ExecutorService接口的系列ThreadPoolExecutor因为都没有显示的设置拒绝策略，所以默认的都是这个。但是请注意，ExecutorService中的线程池实例队列都是无界的，也就是说把内存撑爆了都不会触发拒绝策略。当自己自定义线程池实例时，使用这个策略一定要处理好触发策略时抛的异常，因为他会打断当前的执行流程。

三、DiscardPolicy(丢弃策略)

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

四、DiscardOldestPolicy(弃老策略)

这个策略依然会丢弃任务，丢弃时也是无声无息，但丢弃的是老的未执行的任务，而且是待执行优先级较高的任务。基于这个特性，我能想到的场景就是，发布消息，和修改消息，当消息发布出去后，还未执行，此时更新的消息又来了，这时未执行的消息的版本比现在低就可以被丢弃了。因为队列中还可能存在消息版本更低的消息会排队执行，所以在真正处理消息的时候一定要做好消息的版本比较。此拒绝策略，是一种喜新厌旧的拒绝策略。是否要采用此种拒绝策略，还得根据实际业务是否允许丢弃老任务来认真衡量。

第三方实现的拒绝策略

dubbo中的线程拒绝策略

可以看到，当dubbo的工作线程触发了线程拒绝后，主要做了三个事情，原则就是尽量让使用者清楚触发线程拒绝策略的真实原因。

输出了一条警告级别的日志，日志内容为线程池的详细设置参数，以及线程池当前的状态，还有当前拒绝任务的一些详细信息。可以说，这条日志，使用dubbo的有过生产运维经验的或多或少是见过的，这个日志简直就是日志打印的典范，其他的日志打印的典范还有spring。得益于这么详细的日志，可以很容易定位到问题所在。

Netty中的线程池拒绝策略

Netty中的实现很像JDK中的CallerRunsPolicy。不同的是，调用者运行策略是直接在调用者线程执行的任务。而 Netty是新建了一个线程来处理的。所以，Netty的使用面就可以扩展到支持高效率高性能的场景。但也要注意，Netty的实现里，在创建线程时未做任何的判断约束。

pinpoint中的线程池拒绝策略

pinpoint的拒绝策略实现很有特色，与众不同。他定义了一个拒绝策略链，包装了一个拒绝策略列表，当触发拒绝策略时，会将策略链中的rejectedExecution依次执行一遍

"Java线程池拒绝策略是什么"的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！