《ExecutorService-10個要訣和技巧》讀後總結

譯文：http://www.importnew.com/20263.html 原文：http://www.nurkiewicz.com/2014/11/executorservice-10-tips-and-tricks.html

不轉發全文了，寫點本身的觀點

第一點很強烈使用。無論用什麼方式，最好都對本身的線程命名，這對調試頗有幫助。你應該知道不使用 Google Guava 的狀況下如何自定義線程池中的線程。固然，實際開發中最好能用 Guava 就用，減小重複代碼。

第二點是進階的線程命名技巧，能用最好，可是我不知道對實際工做的幫助有多大，確定是對調試有點用的。

第三點，使用線程池必定要知道 shutdown 和 shutdownNow 的異同，根據狀況選擇使用

第四點，線程中斷機制必定要了解，很少解釋

第五點，線程池隊列必定要保持優先長度，默認的20億太大了。而且最好能監控

第六點，正常狀況使用線程池不少人都會，報異常以後怎麼處理就未必了。開發人員須要知道使用 execute 執行任務如何處理異常，使用 submit 執行任務如何處理異常。在這一點上，即使是 Spring 框架也會犯錯。看看 Spring 4.0 中 @Async 任務是如何處理異常的，答案是沒處理，從新拋出來。問題是在使用 @Async 註解實現異步任務的場景中，又有誰會執行 Future.get() 來獲得從新拋出的異常呢？因此，稍不注意，異常就靜悄悄地丟了。Spring 4.1 以後改進了這個問題，感興趣的能夠看一下 Spring 的源代碼：https://github.com/spring-projects/spring-framework/blob/4.0.x/spring-aop/src/main/java/org/springframework/aop/interceptor/AsyncExecutionInterceptor.java

因此，不管是使用原生的線程池仍是 Spring 的線程池，都須要瞭解線程池中異常的處理機制。

注：這一段譯文翻譯有錯

第七點，監控任務在隊列中等待的時間

第八點，可能80%狀況下不用這麼作也能解決問題，可是剩下20%可能就須要這種方法幫助你更好地調試程序

第九點，其實我對 CompletableFuture 並不感冒，方法太多了，看的頭暈。我更喜歡 Guava 和 Spring 裏的 ListenableFuture。不過 CompletableFuture 畢竟是 JDK 提供的，並且做者仍是大名鼎鼎的 Doug Lea，看來只怪本身學藝不精了。

第十點，不作解釋，感興趣能夠看看源代碼