那天下午，我正在排查一个线上问题。应用突然变慢，接口响应时间从 50 毫秒飙到 3 秒。第一反应是数据库扛不住了，但 DBA 说数据库 CPU、IO 都正常，连接数也没到上限。于是就奇怪了。我随手在服务器上敲了个 ，发现大量线程阻塞在 上。好家伙，数据库连接池被掏空了。这情形太典型了，就像超市排队结账，明明有 10 个收银台，却每个窗口前都堵着人，后面的人只能干等着。
用 Arthas 查看数据库连接池，本质上就是看两件事：连接池的“库存”还剩多少，以及这些连接被谁占着不放。不同连接池实现类略有差异，但核心思路一致。比如 HikariCP，你可以用 命令直接调用它的 方法，或者用 表达式从 Spring 容器里把 DataSource 捞出来，再一层层剥开。我习惯先跑个 看看当前阻塞的线程在等什么，十有八九会看到 之类的报错。到这时，你就知道方向对了。
有一次我遇到更隐蔽的问题。连接池明明显示有 10 个空闲连接，但应用就是拿不到。用 Arthas 的 命令盯着 ，发现每次调用都会先走一个 的校验逻辑。原来有人把连接超时时间设成了 100 毫秒，而数据库偶尔响应慢到 200 毫秒。连接池不是没有连接，而是每次拿连接都超时了。这种坑光看监控面板根本发现不了，必须用工具钻进代码里才能揪出来。
说到具体操作，我常用的三板斧是这样的。第一斧：这行命令直接拿到 HikariCP 的活动连接数。第二斧： 找出最忙的 5 条线程，看看它们持有哪些连接。第三斧：，监控连接的获取过程。这三招下来，连接池的问题基本能定位个七七八八。
但光看数据还不够，得学会读“潜台词”。比如活动连接数一直在涨，而线程数不变，说明每个连接的处理时间变长了。这时可以用 命令盯一下 SQL 执行链路，看看是否有慢查询把连接占着不放。再比如空闲连接不少，但新请求仍在等待，可能是 与 配置不合理，或者某个连接被标记为不可用却没及时回收。这些细节，Arthas 能让你像看 X 光片一样把问题照得清清楚楚。
记得有次线上事故，凌晨两点报警，数据库连接池全满。我远程连上去，先跑了 ，发现所有阻塞线程都在等同一个表上的行锁。随后用 查那个表对应的实体类，发现有个批量更新操作没有走索引，导致全表扫描加行锁，直接把连接池拖垮。修复方案很简单：加索引并把批量操作拆成小批次。如果没有 Arthas，可能要翻半天日志才能定位到是哪个 SQL 在作怪。
说到这里，不得不提一个常见误区。很多人以为连接池问题就是配置问题，调大 就能解决。但 Arthas 往往告诉你，根本原因是连接被“浪费”。比如事务没及时提交、连接泄漏、或者某个 API 调用超时后连接未释放。用 命令查看线程堆栈，你能清晰看到哪个线程在执行 之前卡住了。这类问题，单纯调大连接池只是掩耳盗铃。
说点实在的。排查连接池问题时，Arthas 是手术刀，不是锤子。别一上来就乱敲各种命令。我一般先跑 看整体状态，再用 看线程分布，随后才用 、 这些精细工具。而且记得加上执行次数限制，比如 只抓 5 次，避免对线上环境造成二次压力。连接池问题千奇百怪，但万变不离其宗：要么是池子太小，要么是连接被占用太久，要么是拿连接的过程本身出了岔子。Arthas 能帮你把这三个问题都量化、可视化，剩下的就是根据数据做决策。工具再好，关键还是要读懂它告诉你的信息。
