摘要:最近針對某系統做了次壓力測試，在併發較高的時候暴露了一個maxIdle設定不合理的問題，特總結一下這次問題，並分析一下這個問題背後的原因。

問題現象

用60個執行緒併發訪問某個讀和寫均有的業務介面，效能測試人員檢視Oracle資料庫負載CPU非常高，而且oracle的Logons指標達到148.1次/秒（這個值的含義是資料庫客戶端登入認證的每秒的次數）。

而且檢視應用程式中的執行緒棧，也發現了較多數量的執行緒處於建立新的oracle物理連線處。

這當時就讓我有點兒糊塗了，我們不是用了連線池嗎？怎麼還會經常建立物理連線呢？

問題分析解決

遇到這個問題，我當時也是從自己掌握的各種知識裡去想可能的原因，都想到了是不是因為

所以我就簡單開發了一個頁面可以實時檢視當時應用連線池的active number（當前被使用的資料庫連線數）和idle number（當前處於空閒狀態的資料庫連線數）。再次執行測試指令碼，通過檢視連線池的連線數就可以看出來，連線數的波動較大，有時候連線總數（上面兩個數字相加）從20多突然降到10，說明物理連線被銷燬了，建立了新的物理連線，那這就與我們看到的一些異常現象相吻合了，建立新的連線就會導致

網上找到一篇文章詳細介紹dbcp連線池配置的，它關於maxIdle的配置說明是這麼寫的。

maxIdle值與maxActive值應配置的接近。 因為，當連線數超過maxIdle值後，剛剛使用完的連線（剛剛空閒下來）會立即被銷燬。而不是我想要的空閒M秒後再銷燬起一個緩衝作用。這一點DBCP做的可能與你想像的不一樣。 若maxIdle與maxActive相差較大，在高負載的系統中會導致頻繁的建立、銷燬連線，連線數在maxIdle與maxActive間快速頻繁波動，這不是我想要的。 高負載系統的maxIdle值可以設定為與maxActive相同或設定為-1(-1表示不限制)，讓連線數量在minIdle與maxIdle間緩衝慢速波動。

看到這個我明白了因為我們的配置是maxIdle配置的值是5，而maxActive配置的值為40，這樣當併發較高的時候，當連線數接近maxActive值的情況下，空閒連線數很容易超過maxIdle，很快就被連線池給主動銷燬了，這樣就導致了連線頻繁的建立，弱化了資料庫連線池的作用。

這次的效能測試然讓我深刻的感受到了資料庫連線池對的價值，使用得當，它能夠很好地複用已有的物理連線，在高併發的場景下，減少頻繁的建立和銷燬物理連線，降低系統的壓力。用得不好，它的價值就發揮不出來，就像咱們今天這個案例一樣。

為什麼是這樣的？

maxIdle的值為什麼要與maxActive的接近呢？果真如此嗎？我們還要通過原始碼來分析它背後的根本原因。

看看上圖是對dbcp連線池的獲取和歸還連線物件的流程圖的描述，通過該圖我們就一目瞭然了。

maxIdle配置總結

maxIdle值與maxActive值應配置的接近。

因為，當連線數超過maxIdle值後，剛剛使用完的連線（剛剛空閒下來）會立即被銷燬。而不是我想要的空閒M秒後再銷燬起一個緩衝作用。這一點DBCP做的可能與你想像的不一樣。

若maxIdle與maxActive相差較大，在高負載的系統中會導致頻繁的建立、銷燬連線，連線數在maxIdle與maxActive間快速頻繁波動，這不是我們想要的。

高負載系統的maxIdle值可以設定為與maxActive相同或設定為-1(-1表示不限制)，讓連線數量在minIdle與maxIdle間緩衝慢速波動。多餘的空閒連線等待回收執行緒來緩慢回收。

至於具體多少合理取決於大家的具體應用場景，但是配置的原則是這樣的：

1.如果是連線池命中率（即應用在獲取連線時直接獲得已經建立物理連線的比率）優先的應用。適合連線資源較充裕的環境，可以儘可能將maxIdle設定得更大一些，多數應用設定的大一些會更加安全。

2.如果是連線資源利用率（即被使用連線佔的比率）優先的應用。適合那些連線資源緊張的環境。可以儘可能將maxIdle設定得更小一些，這樣空閒連線能夠得到更快的釋放，保持一個較小的連線，但是設定的過小的話會導致連線池命中率非常低，弱化連線池的作用。