本文主要是介绍记一次com.mysql.jdbc.exceptions.jdbc4.CommunicationsException异常排查，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
具体异常为：
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 51,440,515 milliseconds ago. The last packet sent successfully to the server was 51,440,517 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
8589f98c3c60: at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
8589f98c3c60: at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
8589f98c3c60: at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
8589f98c3c60: at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
8589f98c3c60: at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
8589f98c3c60: at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:990)
8589f98c3c60: at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3746)
8589f98c3c60: at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2509)
8589f98c3c60: at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2680)
8589f98c3c60: at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2484)
8589f98c3c60: at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1858)
8589f98c3c60: at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1966)
8589f98c3c60: at com.alibaba.druid.filter.FilterChainImpl.preparedStatement_executeQuery(FilterChainImpl.java:3188)
8589f98c3c60: at com.alibaba.druid.filter.FilterEventAdapter.preparedStatement_executeQuery(FilterEventAdapter.java:465)
8589f98c3c60: at com.alibaba.druid.filter.FilterChainImpl.preparedStatement_executeQuery(FilterChainImpl.java:3185)
8589f98c3c60: at com.alibaba.druid.proxy.jdbc.PreparedStatementProxyImpl.executeQuery(PreparedStatementProxyImpl.java:181)
8589f98c3c60: at com.alibaba.druid.pool.DruidPooledPreparedStatement.executeQuery(DruidPooledPreparedStatement.java:227)这个问题首先排查到的是，druid的session没有清理没有用的session导致的，网上也有很多这种解决版本，关于druid的配置都配上了，在本地断点调试的时候，都能发现当异常的时候，没用的session都会被清除。那为什么还一直报以上的异常呢，后面发现并不是druid的问题，是我们使用了spring的事务管理，我们用的是编程式事务，当有一个connection开启了事务之后，它会把connection存储在一个TransactionSynchronizationManager的
ThreadLocal<Map<Object, Object>> resources =new NamedThreadLocal<>("Transactional resources");这里是跟线程有关的，当用线程池访问时候，如果你不清空这个resources ，里面的connection就会一直都在，也就是说一直可以被拿出来执行，但是对于数据库来说，一个connection默认是8个小时就会被收回，变为无用的状态，如果resource这里面的connection一直不清理就一直报这个错误，那至于怎样清理这个session？如果是编程式事务，需要调用commit或rollback，里面就会调用cleanupTransactionInfo()来清理这个connection，所以这次的异常根本原因就是我们代码中存在没有commit或rollback一个connection，所以使用编程式事务一定要很小心。
重现代码块：
public void test2() {try{PlatformTransactionManager transactionManager = transactionTemplate.getTransactionManager();TransactionStatus transactionStatus = transactionManager.getTransaction(new DefaultTransactionDefinition(TransactionDefinition.PROPAGATION_REQUIRED));//DruidPooledConnection connection = druidDataSource.getConnection();//PreparedStatement statement = connection.prepareStatement("select 1");int i = swjDao.execute("update bd_stock set name = \"code71\" where id = \"02daa8\"",new HashMap<>());System.out.println(i);System.out.println("test2");//transactionManager.rollback(transactionStatus);//transactionManager.commit(transactionStatus);// connection.close();}catch (Exception e){e.printStackTrace();}}
这篇关于记一次com.mysql.jdbc.exceptions.jdbc4.CommunicationsException异常排查的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
