聊聊hikari與tomcat jdbc pool的fail fast
序
本文主要研究在中途資料庫掛的情況下，hikari與tomcat jdbc pool的fail fast情況。
實驗代碼
在第一次循環輸出之後斷開資料庫連接，等個二三十秒再恢復。
hikari
從這點來看，中途資料庫斷開的話，hikari會不斷獲取資料庫鏈接
假設資料庫一直沒恢復，那麼所以請求資料庫操作的業務線程將都阻塞connectionTimeout的時間，這個會佔用工作線程
hikari只有testOnBorrow功能，是直接一個while循環，在timeout時間內不斷borrow連接，validate連接，validate成功才返回或者超時拋出SQLTransientConnectionException異常。borrow的超時時間為connectionTimeout，默認30秒。
validate不成功日誌記錄的異常
假設在測試之前新建立好maxPoolSize的連接，那麼執行之後中斷資料庫，則下一次的getConnection會挨個取出這些空閑連接，validate，validate失敗會在log裡頭記錄異常，同時getConnection繼續循環獲取連接
getConnection timeout拋出的異常
循環獲取連接超時，則拋出SQLTransientConnectionException
非同步線程PoolEntryCreator補充新連接在日誌記錄的異常
獲取連接的源碼
HikariCP-2.7.6-sources.jar!/com/zaxxer/hikari/pool/HikariPool.java
tomcat
tomcat jdbc pool有testOnBorrow,testOnReturn,testOnConnect,testWhileIdle屬性來配置什麼時候檢測連接，如果是testOnBorrow的話，有空閑連接則進行borrow同時進行validate，如果上一次validate的時間在validation interval內，則默認validate成功，否則進行validate，validate失敗會進行reconnect，再validate，如果再失敗則拋出new SQLException(「Failed to validate a newly established connection.」)。如果沒有空閑連接，且連接池沒滿就創建一個新的；如果沒有空閑連接且連接池滿了，則while輪詢空閑隊列，如果沒取到連接，若沒超過maxWait則繼續，超過則拋出PoolExhaustedException。如果沒有空閑連接，且連接池滿了，則borrow超時時間為maxWait默認30秒。
這個示常式序，每次循環都會先歸還連接再sleep，因此連接池始終有空閑連接，只是testOnBorrow校驗不成功，進行了reconnect，在reconnect拋出了異常
reconnect拋出的異常
獲取連接的源碼
tomcat-jdbc-8.5.23-sources.jar!/org/apache/tomcat/jdbc/pool/ConnectionPool.java
小結
如果是沒有空閑連接且連接池滿不能新建連接的情況下
如果是有空閑連接的情況
假設資料庫是掛的，但還有空閑連接，tomcat的testOnBorrow=true。對比可以發現
hikari在獲取一個連接的時候，會在connectionTimeout時間內循環把空閑連接挨個validate一次，最後timeout拋出異常；之後的獲取連接操作，則一直阻塞connectionTimeout時間再拋出異常
tomcat jdbc pool則是在獲取一個連接的時候，先borrow出來連接，正常validate失敗會reconnect，再validate，通常reconnect的時候拋出了ConnectException: Connection refused，然後業務程序會fail fast，之後的獲取連接也都是fail fast的
由此可見，hikari如果connectionTimeout如果設置太大的話，在資料庫掛的時候，很容易阻塞業務線程，而tomcat jdbc pool則會fail fast。
另外hikari是非同步去建立minIdle大小的連接，而tomcat是同步的建立initial-size的連接。
TAG:碼匠的流水賬 |