MySQL异常【数据库断开连接】：Communications link failure

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

异常描述 这个异常通常有如下信息：

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failureThe 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 ，即申请连接的时候先试一试连接是否可用，不过带来的影响就是性能降低，需要根据实际需求合理取舍。 作者： 苍枫露雨 　　　　 出处： http://www.cnblogs.com/chrischennx/ 　　　　 本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。