Jhipster 解决java.util.concurrent.RejectedExecutionException

基础框架 : 基于springboot1.5的JHipster框架

 

报错异常 :java.util.concurrent.RejectedExecutionException

提交的任务被线程池拒绝了...

这里有三个基本概念

 

ThreadPoolExecutor将根据corePoolSize和maxPoolsize设置的边界自动调整池大小.当新任务在方法execute(java.lang.Runnable)中提交时,如果运行的线程少于corePoolSize,则创建新线程来处理请求,即使其他辅助线程是空闲的.如果运行的线程多于corePoolSize而少于maxPoolSize,则仅当队列满时才创建新的线程.如果设置的corePoolSize和maxPoolSize相同,则创建了固定大小的线程池.如果将maxPoolSize设置为基本的无界值(如Integer.MAX_VALUE),则允许线程池适应任意数量的并发任务.

 

保活时间

如果池中当前有多于corePoolSize的线程,则这些多出的线程在空闲时间超过keepAliveTime时将会终止.

 

保持活动时间

如果池中当前有多于corePoolSize的线程,则这些多出的线程在空闲时间超过keepAliveTime时将会终止.

 

排队

所有BlockQueue都可用于传输和保持提交的任务.可以使用队列与池大小进行交互;

如果运行的线程少于corePoolSize,则Executor始终首选添加新的线程,而不进行排队.

如果运行的线程等于或多于corePoolSize,则Execute始终首选将请求加入队列,而不添加新的线程.

如果无法将请求加入队列,则创建新的线程,除非创建比线程超出maxPoolSize,在这种情况下,任务将RejectedExecutionException,开始的异常.

排队通用策略

直接提交

    工作队列的默认选项是synchronousQueue，它将任务直接提交给线程而不保持它们。在此，如果不存在可用于立即运行任务的线程，则试图把任务加入队列将失败，因此会构造一个新的线程。此策略可以避免在处理可能具有内部依赖性的请求集时出现锁。直接提交通常要求无界maximumPoolSizes以避免拒绝新提交的任务。当命令以超过队列所能处理的平均数连续到达时，此策略允许无界线程具有增加的可能性。

无界队列

    使用无界队列（例如，不具有预定义容量的LinkedBlockingQueue）将导致在所有corePoolSize线程都忙时新任务在队列中等待。这样，创建的线程就不会超过corePoolSize（因此，maximumPoolSize的值也就无效了）。

 

有界队列

     当使用有限的maximumPoolSizes时，有界队列（如ArrayBlockingQueue）有助于防止资源耗尽，但是可能较难调整和控制。队列大小和最大池大小可能需要相互折衷：使用大型队列和小型池可以最大限度的降低CPU使用率、操作系统资源和上下文切换开销，但是可能导致人工降低吞吐量。如果任务频繁阻塞，则系统可能为超过您许可的更多线程安排时间，使用小型队列通常要求较大的池大小，CPU使用率较高，但是可能遇到不可接受的调度开销，这样可会降低吞吐量。

 

解决方案

1. 尽量调大maximumPoolSize，例如设置为Integer.MAX_VALUE(简单粗暴....但是对机器的性能要求较高)

2. 使用其他排队策略，例如LinkedBlockingQueue

 

 

原文摘自

https://blog.csdn.net/wzy_1988/article/details/38922449