记一次数据库奔溃重启后 druid 数据源无法恢复连接的生产问题的解决过程

有点绕的标题^_^，事故背景：行里的某减负系统的 oracle 因为不可描述的原因整个虚拟机挂了，故障发生后，所有交易马上从减负系统切回了原系统。经过一段时间的抢修后，数据库恢复了，交易从原系统切回减负系统后，却出现了大量的异常交易，赶紧的又把交易切回了原系统，打开减负系统的日志一看，一堆 getConnection timeout retry 的日志，试着把其中一个应用重启后，连接恢复正常，但是没重启的其他应用服务器都一直在刷 getConnection timeout retry 的日志与错误堆栈 com.alibaba.druid.pool.GetConnectionTimeoutException(……)。

隐隐有些不好的预感。阿里的druid不是能自动恢复连接的吗？但既然清楚了问题所在后，也没头绪，就先把日志打包了回去，期间还抓了4次java core，一同带了回去分析。

看了日志与堆栈，指向的全是获取连接超时的代码段，未能定位问题。不管如何，先看看问题是如何出现的吧，先复现，能复现就能解决。在测试环境上我们试着在交易的过程中，重启虚拟机，重启数据库，的确复现了几乎同样的日志与堆栈，但是只要oracle一恢复服务，连接池就回归正常，无法复现！还有一点让我觉得疑惑的就是上面说的几乎一样的堆栈，实际上我们复现出来的异常堆栈，是带有创建连接异常信息的，但生产上的堆栈却是没有的，百思不得其解。

既然复现无望了，那就读代码吧，对于druid的使用，我们更多的是经验使用，没有真正了解它的原理，这回生产问题紧急，先硬着头皮上了。先从错误堆栈往上推读，找异常的原因，首先是因为ConnectionHolder为空，holder为空是因为获取连接时候返回为空了，而为什么返回为空？要么是因为等待获取超时了，要么是因为连接池中本身就错误地放置了一个null的holder。

看起来好像已经有明目了，但实际上到此处就断了线索了，因为每一种holder的返回都有复杂的情况条件，我仅仅看到代码，没有实际条件参数的辅助判断，根本就不知道问题所在。但实在也没有更多的办法，只能先继续了解druid的原理，继续读它的代码。期间了解到，druid 是使用两个独立线程做连接的创建与回收的，通过执行一段无限循环的代码，它巧妙的使用了empty与notEmpty两个对象的等待与唤醒机制，当无需连接时候，使用empty wait挂起创建连接的线程，而当连接池需要连接的时候，发送empty信号，然后使用 notEmpty wait使获取线程等待，创建连接的线程empty wait收到empty释放信号后，马上进行连接创建，成功后把连接加到池里，同时发出 notEmpty的信号，这时获取连接的线程就会被唤醒，获取刚刚创建的新连接。

代码读过了，但是依然无解，无法解释为何会没有发生创建的异常，却一直没有获取到连接，留给我们解决的时间不多了。这时候我们唯有祭出阿里的调试好器 arthas（一个线上debug工具，甚至更强），拉上组里面会使用这个工具的同事到生产环境去解决问题。

使用arthas attack 到生产的程序后，首先我们观察了连接池的情况，正常！没有连接，连接池数量计算器也显示是0，排除了连接池异常放置连接的可能！接下来，只有一种情况可能返回空，就是获取连接过程中的 notEmpty 等待超时，程序显式返回null。

那么为什么在线程发出了空信号后，创建连接的线程没有在超时时间内为其创建出连接呢？数据库是好的，而且druid没有收集到创建异常。这时候我们再次使用arthas直接调用了创建连接的方法，成功创建，操作系统与数据库之间多了一条连接！这就让我们就有点懵逼了，难道是druid的代码设计出问题了？收到了信号，但线程却没有被唤醒，导致一直没有创建连接？

到此处又断了线索，但组里面的另一位大神在观察系统线程时候，我们发现创建连接的线程是正在运行的，而不是 time wait的，当时没太留意，就是仅仅好奇。就这样后面也没太大进展，使用arthas当晚，应用投产新功能，重启了所有的机器，至此所有的现场消失，原因也仍然没找到。

隔天后不甘心，重新打开了前两天获取的 java core 再分析，突然发现创建连接线程的堆栈也在我们抓取的堆栈里面，而且也是 runnable 状态，并不是没有创建连接时候的 time wait状态，我们在不同的时间间隔抓取了4次，这4次均存在这个线程的堆栈，堆栈显示线程运行中，而且正在跑的是 socket 的 read 方法，至此终于开窍，发现其实并非信号量没用，而是上一次进行数据库连接创建时，到进行堆栈抓取，甚至我们使用 arthas 观察那时，创建连接的线程一直卡住了在 read 方法中，所以无论我们发多少信号，因为循环没有往回跑，所以不可能创建新的连接，也不可能产生创建的异常！

最后结论就是因为某种特殊的挂机原因，使底层进行数据库连接时永不返回导致应用无法再创建新连接，从而造成的这次生产事件。

针对这种情况，后续我们一是决定打开所有应用的监控，从应用内部可第一时间发现问题，及时上送报警，无需等交易失败报警再应对异常。二是继续往下追，看是否存在可以设置连接超时时间的可能并验证，添加杜绝该情况再发生的配置。同时这次查错也让我们获益良多，arthas的使用，java core的获取与分析，druid的源码解读等。本次的记录就次结束，算是一次回顾与总结，与大家共同学习进步。