摘要:最近針對某系統做了次壓力測試，在併發較高的時候暴露了一個maxIdle設置不合理的問題，特總結一下這次問題，並分析一下這個問題背後的原因。
問題現象
用60個線程併發訪問某個讀和寫均有的業務接口，性能測試人員查看Oracle數據庫負載CPU非常高，而且oracle的Logons指標達到148.1次/秒（這個值的含義是數據庫客戶端登錄認證的每秒的次數）。
而且查看應用程序中的線程棧，也發現了較多數量的線程處於創建新的oracle物理連接處。
這當時就讓我有點兒糊塗了，我們不是用了連接池嗎？怎麼還會經常創建物理連接呢？
問題分析解決
遇到這個問題，我當時也是從自己掌握的各種知識裏去想可能的原因，都想到了是不是因爲tcp連接的超時時間是不是太短，仔細一想這些可能性都排除掉了。然後查看連接池的配置，當時我們的同學告訴我這些配置跟線上的是一樣的，應該沒有問題，我當時是就懷疑是maxIdle設置太小導致的原因，但是沒有什麼具體的依據。
所以我就簡單開發了一個頁面可以實時查看當時應用連接池的active number（當前被使用的數據庫連接數）和idle number（當前處於空閒狀態的數據庫連接數）。再次運行測試腳本，通過查看連接池的連接數就可以看出來，連接數的波動較大，有時候連接總數（上面兩個數字相加）從20多突然降到10，說明物理連接被銷燬了，創建了新的物理連接，那這就與我們看到的一些異常現象相吻合了，創建新的連接就會導致oracle數據庫服務器的logons數量增加。由於連接的複用率較差，導致頻繁的創建物理連接，oracle數據庫的資源消耗增大。
網上找到一篇文章詳細介紹dbcp連接池配置的，它關於maxIdle的配置說明是這麼寫的。
maxIdle值與maxActive值應配置的接近。 因爲，當連接數超過maxIdle值後，剛剛使用完的連接（剛剛空閒下來）會立即被銷燬。而不是我想要的空閒M秒後再銷燬起一個緩衝作用。這一點DBCP做的可能與你想像的不一樣。 若maxIdle與maxActive相差較大，在高負載的系統中會導致頻繁的創建、銷燬連接，連接數在maxIdle與maxActive間快速頻繁波動，這不是我想要的。 高負載系統的maxIdle值可以設置爲與maxActive相同或設置爲-1(-1表示不限制)，讓連接數量在minIdle與maxIdle間緩衝慢速波動。
原文參考： http://elf8848.iteye.com/blog/1931778
看到這個我明白了因爲我們的配置是maxIdle配置的值是5，而maxActive配置的值爲40，這樣當併發較高的時候，當連接數接近maxActive值的情況下，空閒連接數很容易超過maxIdle，很快就被連接池給主動銷燬了，這樣就導致了連接頻繁的創建，弱化了數據庫連接池的作用。
這次的性能測試然讓我深刻的感受到了數據庫連接池對的價值，使用得當，它能夠很好地複用已有的物理連接，在高併發的場景下，減少頻繁的創建和銷燬物理連接，降低系統的壓力。用得不好，它的價值就發揮不出來，就像咱們今天這個案例一樣。
爲什麼是這樣的？
maxIdle的值爲什麼要與maxActive的接近呢？果真如此嗎？我們還要通過源碼來分析它背後的根本原因。
看看上圖是對dbcp連接池的獲取和歸還連接對象的流程圖的描述，通過該圖我們就一目瞭然了。
詳細的原理和源碼分析請看這裏：http://www.myexception.cn/apache/1874092.html
maxIdle配置總結
maxIdle值與maxActive值應配置的接近。
因爲，當連接數超過maxIdle值後，剛剛使用完的連接（剛剛空閒下來）會立即被銷燬。而不是我想要的空閒M秒後再銷燬起一個緩衝作用。這一點DBCP做的可能與你想像的不一樣。
若maxIdle與maxActive相差較大，在高負載的系統中會導致頻繁的創建、銷燬連接，連接數在maxIdle與maxActive間快速頻繁波動，這不是我們想要的。
高負載系統的maxIdle值可以設置爲與maxActive相同或設置爲-1(-1表示不限制)，讓連接數量在minIdle與maxIdle間緩衝慢速波動。多餘的空閒連接等待回收線程來緩慢回收。
至於具體多少合理取決於大家的具體應用場景，但是配置的原則是這樣的：
1.如果是連接池命中率（即應用在獲取連接時直接獲得已經創建物理連接的比率）優先的應用。適合連接資源較充裕的環境，可以儘可能將maxIdle設置得更大一些，多數應用設置的大一些會更加安全。
2.如果是連接資源利用率（即被使用連接佔的比率）優先的應用。適合那些連接資源緊張的環境。可以儘可能將maxIdle設置得更小一些，這樣空閒連接能夠得到更快的釋放，保持一個較小的連接，但是設置的過小的話會導致連接池命中率非常低，弱化連接池的作用。