數據庫鏈接池配置 testOnBorrow

背景

前段時間作系統壓測，發現DB的CPU使用率飆升很嚴重，排查後發現是一個配置testOnBorrow由false修改成true致使。怎麼對性能影響這麼大？須要好好了解一下。

testOnBorrow含義

testOnBorrow：若是爲true（默認爲false），當應用向鏈接池申請鏈接時，鏈接池會判斷這條鏈接是不是可用的。

testOnBorrow=false可能致使問題

假如鏈接池中的鏈接被數據庫關閉了，應用經過鏈接池ge tConnection時，均可能獲取到這些不可用的鏈接，且這些鏈接若是不被其餘線程回收的話；它們不會被鏈接池廢除，也不會從新被建立，佔用了鏈接池的名額，項目若是是服務端，數據庫連接被關閉，客戶端調用服務端就會出現大量的timeout，客戶端設置了超時時間，會主動斷開，服務端就會出現close_wait。

鏈接池如何判斷鏈接是否有效的？

• 經常使用數據庫：使用${DBNAME}ValidConnectionChecker進行判斷，好比Mysql數據庫，使用MySqlValidConnectionChecker的isValidConnection進行判斷
• 其餘數據庫：則使用validationQuery判斷
• 驗證不經過則會直接關閉鏈接，並從新從鏈接池獲取下一條鏈接。

總結

1.testOnBorrow可以確保咱們每次都能獲取到可用的鏈接，可是若是設置爲true，則每次獲取鏈接時候都要到數據庫驗證鏈接有效性，這在高併發的時候會形成性能降低，能夠將testOnBorrow設置成false，testWhileIdle設置成true這樣能得到比較好的性能。

2.testOnBorrow和testOnReturn在生產環境通常是不開啓的，主要是性能考慮。失效鏈接主要經過testWhileIdle保證，若是獲取到了不可用的數據庫鏈接，通常由應用處理異常。

詳見：https://www.jianshu.com/p/edb6a91285be