在使用執行緒池的時候，可能會遇到兩種情況，導致執行緒會需要被拒絕。

• 呼叫 shutdown 等方法關閉執行緒池後，即便此時可能執行緒池內部依然有沒執行完的任務正在執行，但是由於執行緒池已經關閉，此時如果再向執行緒池內提交任務，就會遭到拒絕。
• 執行緒池沒有能力繼續處理新提交的任務，也就是工作已經非常飽和的時候。

執行緒池的拒絕Handler

其實在這裡，我們其實可以想到執行緒池的初始配置中有一個配置handler，這個其實就是為了解決這種問題而出現的，線上程池中，除了我們自己可以定義一個拒絕Handler策略，執行緒池其實也內建了四種不同的拒絕策略供我們使用。

執行緒策略

AbortPolicy（異常策略）

在遇到拒絕任務時，會直接丟擲一個型別為 RejectedExecutionException 的 RuntimeException，所以我會叫他為異常策略，因為他會丟擲異常。這個異常你可以捕獲起來，然後做你想做的事。

DiscardPolicy（丟棄策略）

這個策略就比較悲傷了，當執行緒滿了之後，後面想進來的執行緒會被直接丟棄掉，丟棄掉的執行緒後面不會再執行，也不會有通知，更不會有記錄，所以這個策略比較危險，他會讓執行緒人間蒸發。這樣大家都不知道他有沒有發生過。如果發生在業務上，可能會造成業務資料的丟失。

DiscardOldestPolicy （犧牲策略）

這個就比較殘忍，雖然不會丟棄掉想要擠進來的執行緒，但是他會把執行緒佇列中存活時間久的執行緒給丟棄掉，讓想擠進來的執行緒去替代他。有點像渣男。可以把它叫為渣男策略

CallerRunsPolicy（執行策略）

這個策略就比較負責了，當執行緒池滿了之後，想要進來的執行緒不會被丟棄，他會直接讓提交執行緒的執行緒去執行這個執行緒任務，也是不進入到執行緒池，你直接就地解決吧。更簡單的理解為，當遇到了這個策略，相當於這個執行緒池新增了一個執行緒資源。
這樣的方式有兩點好處

• 新提交的任務不會被丟棄，也就不會造成業務上的損失。
• 新提交的任務會讓提交者的執行緒去執行，這個時候提交者的執行緒就會被阻塞一段時間，這段時間其實會給執行緒池減少一定程度的壓力，減緩了提交者的去提交執行緒的速度。