The last packet successfully received from the server was 1,266,537 milliseconds ago. The last pack

最近接手一个项目，由于该项目对mysql数据库使用频率不是很高，线上每天都会报几十条数据库连接失效的错误信息，刚开始没空处理这个错误，连接失效超时后会继续建立有效连接，不会影响正常的业务。今天抽空处理下这个错误，简单做下总结：

1、线上错误的日志信息如下：

2019-02-23 09:49:35:872 d.s.Statement 149 [ERROR] {conn-10345, stmt-42475} execute error. SELECT 'x'
 com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 1,266,528 milliseconds ago.  The last packet sent successfully to the server was 1,266,529 milliseconds ago.
    at sun.reflect.GeneratedConstructorAccessor69.newInstance(Unknown Source)
    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:981)
    at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3652)

2、错误分析

      分析该错误是由于业务系统使用了过期的数据库连接导致请求超时，和dba确认线上mysql数据库wait_timeout配置的3600s(1小时)、业务线程闲置状态下和数据库保持的连接存活1个小时后数据库主动断开连接，这个时候有新的数据库操作请求、拿到该连接去执行validationQuery检测连接是否有效，由于数据库已经主动断开连接、执行检测sql就会抛出上面的错误。问题的本质还是druid线程池里没有及时清除无效的数据库连接导致。

3、解决办法

  3.1、先分析下目前代码线上的druid参数配置如下：

各个参数的意思不用多说，官网都有详细解释，不明白的自行去搜索。

3.2、看下druid的源码关于线程池连接失效处理逻辑、对应的是com.alibaba.druid.pool.DruidDataSource类下面shrink(boolean checkTime)方法、源码如下：

public void shrink(boolean checkTime) {
        ArrayList evictList = new ArrayList();

        try {
            this.lock.lockInterruptibly();
        } catch (InterruptedException var13) {
            return;
        }

        try {
            // 线程池里的线程总数 - 核心线程池数(上面配置的是10)
            int checkCount = this.poolingCount - this.minIdle;
            long currentTimeMillis = System.currentTimeMillis();

            int i;
            for(i = 0; i < this.poolingCount; ++i) {
                DruidConnectionHolder connection = this.connections[i];
                if (checkTime) {
                    long idleMillis;
                    if (this.phyTimeoutMillis > 0L) {
                        // 当前时间 - 线程的创建时间、大于配置的phyTimeoutMillis（上面配置的1800s）直接强制回收
                        idleMillis = currentTimeMillis - connection.getTimeMillis();
                        if (idleMillis > this.phyTimeoutMillis) {
                            evictList.add(connection);
                            continue;
                        }
                    }

                    idleMillis = currentTimeMillis - connection.getLastActiveTimeMillis();
                    //线程闲置时间小于 最小存活时间（上面配置的300s）直接跳出判断
                    if (idleMillis < this.minEvictableIdleTimeMillis) {
                        break;
                    }
                    //当前线程池数量超过核心线程数（上面配置的10）直接回收掉多余的线程
                    if (checkTime && i < checkCount) {
                        evictList.add(connection);
                    // 闲置时间超过最大存活时间直接清除（上面没有配置 默认）
                    } else if (idleMillis > this.maxEvictableIdleTimeMillis) {
                        evictList.add(connection);
                    }
                } else {
                    if (i >= checkCount) {
                        break;
                    }

                    evictList.add(connection);
                }
            }

            i = evictList.size();
            if (i > 0) {
                System.arraycopy(this.connections, i, this.connections, 0, this.poolingCount - i);
                Arrays.fill(this.connections, this.poolingCount - i, this.poolingCount, (Object)null);
                this.poolingCount -= i;
            }
        } finally {
            this.lock.unlock();
        }

        Iterator var15 = evictList.iterator();

        while(var15.hasNext()) {
            DruidConnectionHolder item = (DruidConnectionHolder)var15.next();
            Connection connection = item.getConnection();
            JdbcUtils.close(connection);
            this.destroyCount.incrementAndGet();
        }

    }

3.3、可以很直观的看到是由于phyTimeoutMillis配置的时间太大(这种是根据线程时间强制回收连接、对系统不是很友好、将参数值调小也能解决问题)、或者添加如下配置来及时清除无效的连接、个人比较推荐这种方式：

3.4、最终调整过后的线上配置如下所示、问题解决：