“不要使用全局的資源池。除非你真的知道它的合理配置——如大小、超時等?！?/p>
我在這個坑里踩了兩次了。
第一次是Http的連接池。我用了一個默認的PoolingHttpClientConnectionManager來進行REST服務調用。沒想到，默認配置下的http連接池中，同一個域名最多只創建兩個鏈接。結果壓力稍微上來一點就瞬間悲劇了。
第二次是線程池。Spring的task:annotation-driven配置會將全局的@Async注解類/方法，以及定時任務都放到同一個線程/任務池中進行異步調用。結果，當其中某些任務阻塞住了工作線程時，系統中一大批多線程操作都超時了。
除了這兩個坑外，我算是成功的躲開了一個坑。
使用Java 8的parallel stream來運行多線程任務時，默認情況下，所有線程由ForkJoinPool.commonPool()來調度、運行。與我第二次踩坑時的問題相似：如果有某些任務阻塞住了工作線程時，其它多線程任務會付出額外的等待時間，甚至超時。
這次我用了自定義的ForkJoinPool來躲開這個坑。并且我提醒自己：使用全局資源池時，一定要慎重。例如，全局的線程池、http/db連接池、緩存池等等。因為“全局”的覆蓋面和影響面都太廣，一個地方的無心之失，就可能導致千百處問題。這樣的風險太大、太不可控了。
不過，數據庫連接池算是一個特例。實際上，數據庫連接池同樣有上面這些風險，只不過大部分情況下，我們對數據庫連接池機制研究以及大小、超時時間等方面的配置已經比較完善了，因此才很少出現影響應用服務的問題。另外，由于數據庫操作實在是太頻繁了，數據庫連接池算是一個剛需，沒它不行。
區分使用資源池，可以起到問題隔離的作用。不過，過多的資源池有時候也會造成資源浪費。雖然這種情形的概率會更小，但是一旦真的出現問題了，那么要定位和解決起來就不是那么容易的了。
我的經驗是，區分一下各類操作的類型（CPU密集運算、數據庫讀寫操作、網絡IO、硬盤IO等），對不同類型操作使用不同資源池（如不同的線程池）；對同一類型的操作，可以再做細分（如內網IO、外網IO等），并以此為依據使用不同的資源池。
但總歸，不要簡單粗暴的使用全局統一的資源池。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
