關於數據庫連接池的最大空閒時間的配置，來源：https://zhaoyanblog.com/archives/486.html
java的所有的連接池 無論是c3p0、dbcp還是druid，都有一個類似maxIdleTime配置項。具體含義就是當連接長時間沒有向服務器發請求的時候，斷開這個連接，避免對數據庫連接的浪費。這個時間不是隨便設的，它的依據是數據庫的連接最大空閒時間。
以mysql爲例，它有個_wait_timeout 參數，你可以通過命令show variables like “%timeout%”查看
+—————————–+———-+
| Variable_name | Value |
+—————————–+———-+
| connect_timeout | 10 |
| delayed_insert_timeout | 300 |
| innodb_flush_log_at_timeout | 1 |
| innodb_lock_wait_timeout | 50 |
| innodb_rollback_on_timeout | OFF |
| interactive_timeout | 28800 |
| lock_wait_timeout | 31536000 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| rpl_stop_slave_timeout | 31536000 |
| slave_net_timeout | 3600 |
| wait_timeout | 28800 |
+—————————–+———-+
wait_timeout默認的時候是8個小時28800秒，但是有時候可能被不經意修改。這個時間表示當連接在28800個時間沒有向服務器發請求的時候，它就會斷開這個連接。
你可以通過set global wait_timeout=60000來修改。不過好像interactive_timeout也必須同時修改纔可以，要不wait_timeout改不了,它會用interactive_timeout的值初始化wait_timeout(這個原理又是另外一回事了).
所以在使用連接池的時候maxWait或者maxIdleTime，這個參數必須設置爲小於wait_timeout的值，否則的話，當你的連接長時間沒和數據庫交互，服務器早把你的連接斷開了，而你的連接池還認爲是有效的連接，除非你設置testOnBorrow或者testOnReturn設置爲true，這樣當連接每次從連接池中取出或者放回的時候檢查下連接是否有效。不過這樣回犧牲一點性能。
否則你就會收到下面這樣類似的異常，特別是經過一個耗時長的查詢之後，這個連接再用於進行下次數據庫操作的時候。
The last packet successfully received from the server was 1,867,460 milliseconds ago. The last packet sent successfully to the server was 0 milliseconds ago.; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure