資源池的兩個(gè)小教訓(xùn)

“不要使用全局的資源池。除非你真的知道它的合理配置——如大小、超時(shí)等。”

我在這個(gè)坑里踩了兩次了。

第一次是Http的連接池。我用了一個(gè)默認(rèn)的PoolingHttpClientConnectionManager來進(jìn)行REST服務(wù)調(diào)用。沒想到，默認(rèn)配置下的http連接池中，同一個(gè)域名最多只創(chuàng)建兩個(gè)鏈接。結(jié)果壓力稍微上來一點(diǎn)就瞬間悲劇了。

第二次是線程池。Spring的task:annotation-driven配置會(huì)將全局的@Async注解類/方法，以及定時(shí)任務(wù)都放到同一個(gè)線程/任務(wù)池中進(jìn)行異步調(diào)用。結(jié)果，當(dāng)其中某些任務(wù)阻塞住了工作線程時(shí)，系統(tǒng)中一大批多線程操作都超時(shí)了。

除了這兩個(gè)坑外，我算是成功的躲開了一個(gè)坑。

使用Java 8的parallel stream來運(yùn)行多線程任務(wù)時(shí)，默認(rèn)情況下，所有線程由ForkJoinPool.commonPool()來調(diào)度、運(yùn)行。與我第二次踩坑時(shí)的問題相似：如果有某些任務(wù)阻塞住了工作線程時(shí)，其它多線程任務(wù)會(huì)付出額外的等待時(shí)間，甚至超時(shí)。

這次我用了自定義的ForkJoinPool來躲開這個(gè)坑。并且我提醒自己：使用全局資源池時(shí)，一定要慎重。例如，全局的線程池、http/db連接池、緩存池等等。因?yàn)椤叭帧钡母采w面和影響面都太廣，一個(gè)地方的無心之失，就可能導(dǎo)致千百處問題。這樣的風(fēng)險(xiǎn)太大、太不可控了。

不過，數(shù)據(jù)庫連接池算是一個(gè)特例。實(shí)際上，數(shù)據(jù)庫連接池同樣有上面這些風(fēng)險(xiǎn)，只不過大部分情況下，我們對(duì)數(shù)據(jù)庫連接池機(jī)制研究以及大小、超時(shí)時(shí)間等方面的配置已經(jīng)比較完善了，因此才很少出現(xiàn)影響應(yīng)用服務(wù)的問題。另外，由于數(shù)據(jù)庫操作實(shí)在是太頻繁了，數(shù)據(jù)庫連接池算是一個(gè)剛需，沒它不行。

區(qū)分使用資源池，可以起到問題隔離的作用。不過，過多的資源池有時(shí)候也會(huì)造成資源浪費(fèi)。雖然這種情形的概率會(huì)更小，但是一旦真的出現(xiàn)問題了，那么要定位和解決起來就不是那么容易的了。

我的經(jīng)驗(yàn)是，區(qū)分一下各類操作的類型（CPU密集運(yùn)算、數(shù)據(jù)庫讀寫操作、網(wǎng)絡(luò)IO、硬盤IO等），對(duì)不同類型操作使用不同資源池（如不同的線程池）；對(duì)同一類型的操作，可以再做細(xì)分（如內(nèi)網(wǎng)IO、外網(wǎng)IO等），并以此為依據(jù)使用不同的資源池。

但總歸，不要簡單粗暴的使用全局統(tǒng)一的資源池。