# 背景 这篇文章是写给有缘人的，为什么这么说呢，因为本篇主要讲讲数据库连接池之c3p0-0.9.1.2版本。 年轻的朋友，可能没怎么听过c3p0了，或者也仅限于听说，这都很正常，因为c3p0算是200几年时比较流行的技术，后来，作者消失了好几年，12年重新开始维护，这时候已经出现了很多第二代线程池
# 背景 本篇是c3p0连接泄露问题的第二篇，在前面一篇里面，大体介绍了问题，问题就是，我们发现线上服务不响应的原因是拿不到连接。而为啥拿不到连接呢，因为空闲链表为空，那么为什么空闲链表为空呢？ 这个我一开始的猜测就是，估计是某处代码从连接池里获取了连接，用完了没有归还，那么，怎么才能找到这些罪恶的
# 前言 本篇其实是承接前面两篇的，都是讲定位线上的c3p0数据库连接池，发生连接泄露的问题。 第二篇讲到，可以配置两个参数，来找出是哪里的代码借了连接后没有归还。但是，在我这边的情况是，对于没有归还的连接，借用者的堆栈确实是打印到日志了，但是我在本地模拟的时候，发现其实这些场景是有归还连接的，所以
# 背景 我前面写了几篇文章，讲c3p0数据库连接池发生了连接泄露，但是随机出现，难以确定根因，最终呢，为了快速解决问题，我是先写了个shell脚本，脚本主要是检测服务的接口访问日志，看看过去的30s内是不是接口几乎都超时了，如果是的话，咱们就重启服务。然后把这个shell加入到了crontab里，
# 背景 怎么会讲这个话题，这个说来真的长了。但是，长话短说，也是可以的。 我前面的文章提到，线上的服务用了c3p0数据库连接池，会偶发连接泄露问题，而分析到最后，又怀疑是db侧主动关闭连接，或者是服务所在机器和db之间有防火墙，防火墙主动关闭了连接。导致我们这边socket看着还健康，实际在对端已
