假設你的數據庫是mysql，如果數據源配置不當，將可能發生經典的“8小時問題”。原因是mysql在默認情況下，如果發現一個連接的空閑時間超過8小時，將會在數據庫端自動關閉這個連接。而數據源并不知道這個連接已經關閉了，當它將這個無用的連接返回給某個dao時，dao就會報無法獲取connection異常。

如果采用dbcp的默認配置，由于testOnBorrow屬性的默認值是true，數據源在將連接交給dao前，會事先檢測這個連接是否是好的，如果連接有問題(在數據庫端被關閉)，則會取一個其他的連接給dao。所以并不會有“8小時問題”。如果每次將連接交給dao時都檢測連接的有效性，在高并發的應用中將會帶來性能的問題，因為它會需要更多的數據庫訪問請求。

一種推薦的高效的方式是：將testOnBorrow設置為false，而將“testWhileIdle”設置為true，再設置好testBetweenEvictionRunsMillis值(小于8小時)。那些被mysql關閉的連接就可以別清除出去，避免“8小時問題”。

當然，mysql本身也能調整interactive-timeout(以秒為單位)配置參數，更改空閑連接的過期時間。所以，在設置timeBetweenEvictionRunsmMillis值時，必須首先獲知mysql的空閑連接的最大過期時間。

c3p0對于有效連接的檢測，請參照dbcp配置方式。

以上所述就是本文的全部內容了，希望大家能夠喜歡。

總結

以上是生活随笔為你收集整理的mysql 8小时问题_Mysql经典的“8小时问题”的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。