记一次线下问题排查 SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@21db37de] was not regi...

    自从项目从PSSql数据库切换到mysql后，时长会出现 SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@21db37de] was not registered for synchronization because synchronization is not active。所有页面卡顿，服务基本就挂了，本以为是偶尔事件，结果暴力重启后，一段时间再次出现了。页面出现卡顿，一开始就觉得应该是线程死锁，jvm内存撑满，导致GC频繁。

所以，首先检查jvm。。。

查看cpu情况，top -Hp pid

如图所示，cpu最大才占用2%，内存最大也才5%，所以明显不是线程死锁导致的。

继续排查。。。

查看gc情况，jstat -gc pid

如图，即便Eden区和from区数据满了，但总体的GC情况还是可控的，所以也不是这里的问题。

导出dump文件， jmap -dump:format=b,file=heap.hprof 20210，使用jprofiler查看当前创建对象数。

如图，当前存在的对象，最多的也只有13kb，所以不太可能是内存问题，但很明显jvm内存需要增加了。。。

至此，确认不是jvm问题，开始排除mysql数据库问题。仔细分析接口请求，发现

Creating a new SqlSession

SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@30579c64] was not registered for synchronization because synchronization is not active

JDBC Connection [com.mysql.cj.jdbc.ConnectionImpl@5ad7e3ac] will not be managed by Spring

怀疑是不是请求连接数据库，但连接没有被释放。查看durid连接池的配置。

所有参数都是默认的。上网查找druid参数详解，参考连接 https://blog.csdn.net/weixin_33924770/article/details/94117616

数据库连接池在初始化的时候会创建initialSize个连接，当有数据库操作时，会从池中取出一个连接；　　如果当前池中正在使用的连接数等于maxActive，则会等待一段时间，等待其他操作释放掉某一个连接，如果这个等待时间超过了maxWait，则会报错。默认值并没有设置maxWait，所以估计它会一直等待下去，导致页面卡顿，一直刷不出来。

连接池配置文件中添加参数：

initialSize: 20

min-idle: 20

max-active: 100

max-wait: 3000

time-between-eviction-runs-millis: 60000

至此的确不在出现页面卡顿这个问题了。

 但新的问题来了，只要服务运行一段时间，又会出现报错。。。。

这种报错，表明数据库连接太多，已经将连接池中的连接撑满，导致有再次请求是等待超时，报错。。。。

这就奇怪了，难道是druid，没有管理连接池吗？？难道请求一次，就会新建一个新的连接？？？

查看数据库

数据库最大连接数

show variables like ‘%max_connections%’;

当前连接数

show full processlist;

果然发现每请求一次，就会增加一条连接数。。。

排查代码。。。

最后发现有人在代码里手写开启数据库连接，然后没有关闭，也没有抛出异常。结果我们没有捕获到异常，在完全不知情的情况下，花了几天时间排查问题。。。。。。。。。

    这里做一个问题排查总结，这一次虽然是代码上的问题，但从问题出现，与原因分析，对于一个完全没有jvm故障排查经验的人来说，是一份很好的经历，虽然过程曲折，到从jvm，数据库，到druid连接池配置，都是一次难得的回忆。。。。。

ps：我们也曾经调试过druid配置：removeAbandoned 如果连接泄露，是否需要回收泄露的连接，但也不是这个原因，所以的原因都分析过了，再重新看代码时就会充满怀疑。。