基礎框架 : 基於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
原文摘自