異常解決：Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

異常描述

這個異常一般有以下信息：

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 59,977 milliseconds ago.  The last packet sent successfully to the server was 1 milliseconds ago.
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:404)
        at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:988)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3552)
        at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3452)
        at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3893)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2526)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2673)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2549)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1861)
        at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1962)
        at com.alibaba.druid.pool.DruidPooledPreparedStatement.executeQuery(DruidPooledPreparedStatement.java:227)
        at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:692)
        at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:633)
        ... 20 common frames omitted

緣由分析

當數據庫重啓或數據庫空閒鏈接超過設置的最大timemout時間，數據庫會強行斷開已有的連接，最大timeout時間能夠經過命令show global variables like "wait_timeout";查詢：

mysql> show global variables like "wait_timeout";
+---------------+-------+
| VARIABLE_NAME | VALUE |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.00 sec)

解決辦法

爲了解決這個異常，咱們在配置數據庫鏈接池的時候須要作一些檢查鏈接有效性的配置，這裏以Druid爲例，相關配置以下（更多配置）：

字段名	默認值	說明
validationQuery		用來檢測鏈接是否有效的sql，要求是一個查詢語句，經常使用select 'x'。若是validationQuery爲null，testOnBorrow、testOnReturn、testWhileIdle都不會起做用。
validationQueryTimeout		單位：秒，檢測鏈接是否有效的超時時間。底層調用jdbc Statement對象的void setQueryTimeout(int seconds)方法
testOnBorrow	true	申請鏈接時執行validationQuery檢測鏈接是否有效，作了這個配置會下降性能。
testOnReturn	false	歸還鏈接時執行validationQuery檢測鏈接是否有效，作了這個配置會下降性能。
testWhileIdle	false	建議配置爲true，不影響性能，而且保證安全性。申請鏈接的時候檢測，若是空閒時間大於timeBetweenEvictionRunsMillis，執行validationQuery檢測鏈接是否有效。
timeBetweenEvictionRunsMillis	1分鐘（1.0.14）	有兩個含義：1) Destroy線程會檢測鏈接的間隔時間，若是鏈接空閒時間大於等於minEvictableIdleTimeMillis則關閉物理鏈接。2) testWhileIdle的判斷依據，詳細看testWhileIdle屬性的說明

爲了不空閒時間過長超過最大空閒時間而被斷開，咱們設置三個配置：

validationQuery: SELECT 1
testWhileIdle: true
timeBetweenEvictionRunsMillis: 28000

其中timeBetweenEvictionRunsMillis須要小於mysql的wait_timeout。

可是這種方法沒法避免重啓的狀況，不過通常數據庫不會頻繁重啓，影響不大，若是非得頻繁重啓，能夠經過設置testOnBorrow，即申請鏈接的時候先試一試鏈接是否可用，不過帶來的影響就是性能下降，須要根據實際需求合理取捨。