那天下午，我正对着监控面板发呆。数据库连接数像坐上了火箭，从早上的80一路飙到500多，还在往上蹿。DBA在群里发了十几条消息，说再这么下去，数据库就要罢工了。我翻遍了代码，查了所有能想到的地方，愣是没找到是谁在偷偷申请连接不归还。这种时候，脑子里蹦出来的第一个念头就是：该上Arthas了。
说实话，排查数据库连接池泄漏，最让人抓狂的就是不知道连接被谁拿走了。你盯着代码看半天，每个方法看起来都老老实实的，try-with-resources也写了，连接池配置也合理，可连接数就是降不下来。这就像家里水管漏水，你知道肯定有地方在漏，就是找不到那个裂缝。Arthas就是那个能帮你找到裂缝的工具，它能让你的JVM进程“开口说话”，告诉你每一个连接的去向。
我第一次用Arthas排查连接池泄漏，其实心里也没底。当时的情况比现在更糟，服务已经快被拖垮了，重启只能管半小时。我先把Arthas attach到目标进程上，然后用了命令盯着这个方法。没过多久，屏幕上就开始刷出调用栈信息。那一刻我才明白，原来问题不是出在谁拿了连接不还，而是有段代码在循环里反复创建连接，每次都没走finally块。
很多人有个误解，觉得排查连接池泄漏得靠什么高级工具，或者得看一堆晦涩的监控指标。其实Arthas最常用的几个命令就够了。用来盯方法调用，用来查看方法执行的调用路径，用来分析方法耗时。这三个命令组合起来，基本能覆盖绝大多数连接池问题的排查场景。关键是要找准切入点，通常从和这两个方法下手，因为连接的生命周期就围绕这两个方法转。
有一次，我用查看连接获取的调用栈，结果发现有个异步线程在后台定时任务里偷偷申请连接。这个任务虽然写了块来释放连接，但它在某些异常场景下会提前return，把finally块里的释放逻辑给跳过了。这种bug光靠review代码很难发现，因为你得模拟出那个异常场景才能复现。Arthas的好处就是，它能直接告诉你此刻谁在调用这个方法，调用链是什么，不用你猜。
再说一个更隐蔽的情况。有时候连接泄漏不是因为没有调用close，而是因为连接被包装了一层又一层，你调用的close方法根本没作用到真正的连接上。这种问题用Arthas的命令特别容易看出来——你可以在方法上设置条件表达式，过滤出那些参数异常的调用。比如某个包装类的方法被调用了，但内部的连接对象引用已经丢失，这时候连接实际上还挂在连接池里。
还有一些场景，连接池泄漏和线程池泄漏纠缠在一起。你查连接池发现连接数在涨，但每次涨的时候，活跃线程数也在同步增长。这时候别急着查连接池，先看看线程池是不是有堆积。用Arthas的命令可以查看每个线程的状态，配合参数还能找出最忙碌的那几个线程。很多时候，连接泄漏的根因其实是任务积压，任务处理不过来，连接就一直被占着。
不过Arthas也不是万能的。比如连接池泄漏发生在非常低频的路径上，可能要等很久才能抓到一次现场。这个时候建议配合命令的参数设置观察次数，或者用查看所有匹配的调用。还有一种情况是连接池本身就有bug，比如某些版本的Druid在特定条件下不会正确回收连接，这种问题Arthas能帮你定位到是连接池的实现问题，但最终解决方案还是得升级依赖版本。
我自己的经验是，遇到连接池泄漏先别慌着改代码，花十分钟用Arthas看看现场，往往比盲改一天效率高得多。具体操作步骤也很简单：先一下和的调用情况，确认连接是否真的没有被释放；再用查看调用栈，找到是哪个业务线程在拿连接；用分析一下这个方法链的耗时，看是不是有慢SQL拖住了连接。三步下来，80%的问题都能定位到具体代码位置。
回到开头那次事故，我用Arthas的命令配合条件表达式，锁定了是某个报表查询接口的bug——它在分页查询时，每页都会新建一个连接，但只有一页才释放。问题找到后，一行代码就修复了。第二天早上，连接数稳稳地停在80左右。监控面板上那条平滑的曲线，看着就让人舒心。Arthas这东西，平时用不上觉得它多余，真出了事才发现，它就是排查连接池泄漏的那把最快的手术刀。
