很长的报错，截取
-
ERROR c.a.d.p.DruidDataSource - discard connection -
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure -
-
The last packet successfully received from the server was 44,866 milliseconds ago. The last packet sent successfully to the server was 0 milliseconds ago. -
at sun.reflect.GeneratedConstructorAccessor103.newInstance(Unknown Source) ~[na:na] -
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.7.0_79] -
at java.lang.reflect.Constructor.newInstance(Constructor.java:526) ~[na:1.7.0_79] -
at com.mysql.jdbc.Util.handleNewInstance(Util.java:404) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:981) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3465) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3365) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3805) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2478) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2625) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2551) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1861) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1962) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.alibaba.druid.pool.DruidPooledPreparedStatement.executeQuery(DruidPooledPreparedStatement.java:227) ~[druid-1.0.5.jar:1.0.5] -
at com.jfinal.plugin.activerecord.DbPro.query(DbPro.java:73) [jfinal-2.2.jar:na] -
at com.jfinal.plugin.activerecord.DbPro.query(DbPro.java:100) [jfinal-2.2.jar:na] -
at com.jfinal.plugin.activerecord.Db.query(Db.java:47) [jfinal-2.2.jar:na] -
... -
-
Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost. -
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2957) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3375) ~[mysql-connector-java-5.1.38.jar:5.1.38] -
... 55 common frames omitted
起因和现象：
项目运行后，莫名其妙就在log中看到这个报错，但是数据也能获取到，不影响日常使用，但是看到了总归不爽。
看了下网上的原因：
MySQL服务器默认的“wait_timeout”是28800秒即8小时，意味着如果一个连接的空闲时间超过8个小时，MySQL将自动断开该连接，而连接池却认为该连接还是有效的(因为并未校验连接的有效性)，当应用申请使用该连接时，就会导致上面的报错。
出现异常”The last packet sent successfully to the server was 0 milliseconds ago.“的大部分原因
是由于数据库回收了连接，而系统的缓冲池不知道，继续使用被回收的连接所致的。
解决方法：
1.JDBC的URL中加上属性（旧版本可用，不推荐）
按照错误的提示，可以在JDBC URL中使用autoReconnect属性，实际测试时使用了autoReconnect=true&failOverReadOnly=false，不过并未起作用，
使用的是5.1版本，可能真像网上所说的只对4之前的版本有效。
2.修改MYSQL的配置文件my.ini/my.cnf，添加超时等待参数的最长时间（推荐）
没办法，只能修改MySQL的参数了，wait_timeout最大为31536000即1年，在my.cnf中加入：
[mysqld]
wait_timeout=86400 (1天)
interactive_timeout=7200
重启生效，需要同时修改这两个参数。
3.修改配置，让缓冲池验证链接是否有效
#SQL查询,用来验证从连接池取出的连接
dbcp.validationQuery=SELECT 1
#指明连接是否被空闲连接回收器(如果有)进行检验，如果检测失败，则连接将被从池中去除
dbcp.testWhileIdle=true
#在空闲连接回收器线程运行期间休眠的时间值,以毫秒为单位，一般比minEvictableIdleTimeMillis小
dbcp.timeBetweenEvictionRunsMillis=300000
#在每次空闲连接回收器线程(如果有)运行时检查的连接数量，最好和maxActive一致
dbcp.numTestsPerEvictionRun=50
#连接池中连接，在时间段内一直空闲，被逐出连接池的时间(1000*60*60)，以毫秒为单位
dbcp.minEvictableIdleTimeMillis=3600000
如果在wait_timeout秒期间内，数据库连接(java.sql.Connection)一直处于等待状态，mysql5就将该连接关闭。这时，你的Java应用的连接池仍然合法地持有该连接的引用。当用该连接来进行数据库操作时，就碰到上述错误。这解释了为什么我的程序第二天不能登录 的问题。
你可能会想到在tomcat的数据源配置中有没有办法解决？的确，在jdbc连接url的配置中，你可以附上“autoReconnect=true”，但这仅对mysql5以前的版本起作用。增加“validation query”似乎也无济于事。
原因分析
当数据库重启或数据库空闲连接超过设置的最大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，即申请连接的时候先试一试连接是否可用，不过带来的影响就是性能降低，需要根据实际需求合理取舍。
