Java应用数据库连接泄漏排查实战指南

1. 项目概述：为什么“连接数失控”是压垮系统的无声雪崩

你有没有遇到过这样的场景：系统凌晨三点突然告警，数据库响应时间从50ms飙到3秒，应用接口大面积超时，但CPU、内存、磁盘IO都稳如老狗？查日志没明显报错，重启服务后一切正常，可8小时后又准时复发？我干了12年后端和DBA，见过太多团队在深夜盯着监控面板手足无措，最后发现罪魁祸首不是代码bug，不是SQL慢查询，甚至不是服务器资源不足——而是几百个本该30秒内释放的数据库连接，像幽灵一样卡在会话列表里，持续占用着宝贵的连接槽位，最终把整个连接池拖进死循环。

这个标题里的“连接数失控”，不是指用户并发量高导致的合理连接增长，而是典型的资源泄漏型故障。它横跨三个关键层级：最底层是数据库自身的会话（Session），中间层是Java应用的线程池（Thread Pool），最上层是应用与数据库之间的连接池（Connection Pool）。这三层像齿轮一样咬合运转，任何一个齿轮打滑或卡死，都会让整个链条发出刺耳的噪音。而“泄漏”这个词特别精准——它意味着连接被创建了，却因为某种逻辑缺陷，永远没有被归还给池子，也没有被数据库主动清理。它不报错，不崩溃，只是悄悄地、持续地吞噬资源，直到系统在某个临界点轰然倒塌。

我带过的几个金融和电商项目，有三次重大故障复盘都指向同一个根因：一个未捕获的IO异常导致connection.close()被跳过；一次线程池拒绝策略配置不当，让任务堆积阻塞了连接回收线程；还有一次更隐蔽——ORM框架的懒加载在事务外触发，新开了一个连接却没人负责关闭。这些都不是教科书里的经典错误，而是真实生产环境里，由几十行代码、几处配置、一点疏忽共同酿成的苦酒。所以这篇内容，不讲抽象理论，不列一堆参数公式，只聚焦一件事：当你在监控里看到“当前活跃会话数”曲线像心电图一样持续走高，或者show processlist里躺着上百个Sleep状态的连接时，你该按什么顺序、用哪些命令、查哪些日志、改哪几行代码，才能在30分钟内定位并解决它。适合所有正在用Java（Spring Boot）、MySQL/Oracle/达梦、HikariCP/Druid的工程师，无论你是刚写完第一个CRUD的新手，还是负责SRE的资深架构师，这里的方法论都经过了数十次线上火线验证。

2. 连接数失控的三层结构解析：会话、线程池、连接池如何相互绑架

要真正理解“连接数失控”，必须把数据库、应用容器、连接池这三者看作一个有机整体，而不是割裂的模块。它们之间存在严格的依赖关系和生命周期绑定，任何一层的异常都会像多米诺骨牌一样推倒下一层。下面我用一个真实的订单支付流程来拆解这个链条：

2.1 数据库会话：连接的物理载体与最终归宿

数据库会话（Session）是整个链条的物理终点。当你执行mysql -h 192.168.1.100 -u app_user -p登录时，MySQL服务端就为你创建了一个独立的会话进程，分配了内存、锁资源、事务上下文。这个会话的生命周期由两个因素决定：客户端是否主动断开（close） 和 数据库自身的超时机制（wait_timeout）。

提示：很多人误以为“连接池里取出来的Connection对象”就是数据库会话本身。其实不然。Connection是应用层对数据库会话的抽象封装，它内部持有一个TCP socket和一个会话ID。当调用connection.close()时，真正的动作是：将这个socket标记为“可复用”，并将其放回连接池的空闲队列中，而不是立刻向数据库发送KILL命令。数据库那边的会话依然存在，只是进入了Sleep状态，等待下一次被复用或超时被杀。

这就是为什么你在show processlist里总能看到大量Sleep状态的连接。它们不是“活”的，但也不是“死”的，而是处于一种“待机”状态。MySQL默认的wait_timeout是28800秒（8小时），这意味着一个被放回池子的连接，如果8小时内没被再次使用，数据库才会主动断开它。而你的应用可能只需要30秒就能处理完一个请求。问题就出在这里：如果连接池管理失当，导致连接长期闲置在池子里，数据库的Sleep会话就会越积越多，最终耗尽max_connections上限。

我曾经在一个物流系统里见过最极端的案例：max_connections=1000，但show processlist | wc -l输出是1024。多出来的24个连接，全是Sleep状态，且Time字段显示已存活超过7小时。排查发现，是连接池的idleTimeout配置成了0（永不驱逐），而应用在高峰期后流量骤降，大量连接被创建后就再也没被使用过，硬生生等到了数据库的8小时超时才被清理。这期间，任何新的连接请求都会被拒绝，报错Too many connections。

2.2 应用线程池：连接的消费者与调度中枢

如果说数据库会话是“原材料”，那么应用线程池就是“流水线工人”。在Spring Boot的WebFlux或Servlet容器里，每一个HTTP请求都会被分配给一个工作线程去执行。这个线程会从连接池里借出一个Connection，执行SQL，再将Connection归还。线程池的健康状况，直接决定了连接能否被及时“借”和“还”。

线程池的几个核心参数，每一个都和连接数息息相关：

corePoolSize：核心线程数。它决定了系统能同时处理多少个请求。如果这个值设得太小（比如只有4），而QPS有100，那96个请求就会排队等待。排队的请求不会去借连接，但已经借到连接的线程，如果因为SQL慢或网络抖动而迟迟不归还，就会导致连接被长时间占用。

maxPoolSize：最大线程数。当核心线程全忙时，会创建新线程来处理排队任务，直到达到此上限。如果maxPoolSize远大于连接池的最大连接数（maximumPoolSize），就会出现“线程争抢连接”的现象。100个线程同时想借连接，但池子里只有20个，剩下的80个线程只能阻塞等待，形成线程堆积。

workQueue：阻塞队列。这是最容易被忽视的“压力缓冲区”。如果队列类型选的是LinkedBlockingQueue（无界队列），当请求洪峰到来时，所有来不及处理的请求都会被塞进这个队列里。线程池看起来很“闲”（因为核心线程都在处理），但队列里可能积压了上千个任务。而每个任务在执行前，都需要先从连接池借连接。这就导致连接池瞬间被“预占”一空，后续所有新请求都拿不到连接，全部失败。

我在一个政务服务平台的压测中就踩过这个坑。当时把workQueue设为无界，压测脚本模拟1000并发，结果ThreadPoolExecutor.getQueue().size()峰值达到了2300。而连接池最大连接数只有50。结果就是，前50个请求成功拿到连接并开始执行，后面的2250个请求全卡在getConnection()方法上，线程堆栈里全是HikariPool.getConnection()的park状态。系统看起来没崩溃，但所有新请求都超时了。

2.3 连接池：连接的银行与信用中介

连接池是整个链条的“中央银行”。它负责管理Connection的创建、分发、回收和销毁。主流的HikariCP和Druid，其设计哲学都是“池化+监控+智能驱逐”。但再好的银行，也防不住“赖账”的客户。

连接池的几个关键配置，是排查泄漏的第一道关卡：

maximumPoolSize：池子最多能容纳多少个Connection。它必须小于等于数据库的max_connections，否则必然失败。但更重要的是，它应该略大于应用的maxPoolSize（线程池最大线程数）。理想比例是1.2~1.5倍，为突发流量留出余量。

minimumIdle：池子中始终保留的最小空闲连接数。设为0可以节省资源，但在高并发场景下，每次新建连接都有几百毫秒的TCP握手和SSL协商开销，会导致首请求延迟飙升。我一般建议设为maximumPoolSize * 0.3。

idleTimeout：空闲连接在池中存活的最长时间。这是防止“僵尸连接”的关键。如果设为0，连接永不驱逐，就回到了前面说的“8小时超时”困境。合理的值是300000（5分钟）到600000（10分钟）。

leakDetectionThreshold：连接泄漏检测阈值。这是HikariCP的杀手锏功能。当你设置为60000（60秒）时，如果一个Connection被借出后60秒内没有被归还，HikariCP就会在日志里打印一条警告，并记录下当时借出这个连接的线程堆栈。这是定位泄漏点最直接、最有力的证据，比翻代码快十倍。

这三个层级的关系，可以用一个生活化的比喻来理解：数据库会话是“出租屋”，连接池是“房产中介”，线程池是“租客”。中介（连接池）手里有10套房子（maximumPoolSize=10），租客（线程池）最多能来20个人（maxPoolSize=20）。如果10个租客同时租了10套房，住得很开心，按时交租（close()），那一切安好。但如果其中1个租客租了房后，人消失了（代码里漏了close()），那这套房就永远空置着，中介手里就只剩9套可租。当第11个租客来时，中介只能告诉他“没房了”。而如果中介自己管理混乱，把一套房同时租给了两个人（连接被重复使用），或者忘了登记谁租了哪套房（连接对象被GC，但数据库会话还在），那整个租赁市场就乱套了。我们的排查，就是要去找到那个“消失的租客”，或者“管理混乱的中介”。

3. 实战排查四步法：从监控告警到代码修复的完整路径

面对一个正在发生的“连接数失控”告警，慌乱地重启服务是最糟糕的选择。它掩盖了真相，让你永远无法根治问题。我总结了一套经过数十次线上实战验证的“四步法”，每一步都有明确的目标、工具和判断标准，确保你能像外科医生一样，精准地切开问题，找到病灶。

3.1 第一步：确认症状——用监控和命令快速锁定问题层级

这一步的目标是区分“真泄漏”和“假拥堵”。很多情况下，连接数升高是暂时的、可恢复的，比如一次大促前的预热流量，或者一个定时任务在跑大数据量ETL。你需要在5分钟内做出判断。

操作清单：

查数据库实时会话： 登录数据库服务器，执行show processlist;（MySQL）或select * from v$session where status='ACTIVE' or status='INACTIVE';（Oracle）。重点关注Command列（MySQL）或STATUS列（Oracle）和Time列。如果看到大量Sleep（MySQL）或INACTIVE（Oracle）状态，且Time值普遍大于300（5分钟），基本可以判定是连接泄漏。如果全是Query状态且Time值都很小，那可能是SQL慢查询导致的“真拥堵”，需要另起炉灶优化SQL。

查连接池运行时指标： 如果你用的是HikariCP，访问/actuator/metrics/hikaricp.connections.active（Spring Boot Actuator）或JMX（com.zaxxer.hikari:type=Pool (your-pool-name)）。关键指标有：

active：当前被借出的连接数。如果它持续接近maximumPoolSize，且idle（空闲连接数）长期为0，说明连接被借出后没归还。

threadsAwaitingConnection：等待获取连接的线程数。如果这个值大于0，说明连接池已经“无连接可借”，问题出在连接池或其下游（数据库）。

查应用线程状态： 使用jstack 导出Java线程堆栈。用grep -A 5 -B 5 "getConnection"搜索，看有多少线程卡在获取连接上。如果数量巨大，且堆栈都指向同一个业务方法，那问题很可能就在那个方法里。

注意：jstack命令需要JDK的jps工具先找到Java进程PID。在Docker容器里，可以先进入容器docker exec -it /bin/sh，再执行jps。如果jstack输出里看到大量线程在java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()，那基本可以确定是连接池满了，线程在getConnection()的await()里挂起了。

判断树：

如果show processlist里Sleep连接多，且threadsAwaitingConnection > 0 → 高度疑似连接池泄漏。

如果show processlist里Query连接多，且Time值很大 → 优先排查慢SQL。

如果threadsAwaitingConnection = 0，但active很高，且idle很低 → 可能是连接被借出后，业务逻辑卡住了，没走到close()那一步。

3.2 第二步：定位病灶——利用连接池的泄漏检测与日志追踪

一旦确认是泄漏，下一步就是找到那个“消失的租客”。HikariCP的leakDetectionThreshold就是为此而生的。

启用泄漏检测： 在application.yml中添加：

YAML

复制

1

spring:

2

datasource:

3

hikari:

4

leak-detection-threshold: 60000 # 单位毫秒，60秒

重启应用。当一个Connection被借出后60秒内没有被归还，HikariCP会在日志里打印类似这样的信息：

TEXT

复制

1

WARN com.zaxxer.hikari.pool.ProxyLeakTask - Connection leak detection triggered for connection com.mysql.cj.jdbc.ConnectionImpl@1a2b3c4d, stack trace follows

2

java.lang.Exception: Apparent connection leak detected

3

at com.example.service.OrderService.createOrder(OrderService.java:45)

4

at com.example.controller.OrderController.submit(OrderController.java:22)

5

...

这个堆栈信息，就是你的黄金线索！ 它精确地告诉你，是在OrderService.java的第45行，哪个方法借出了连接，却没有归还。

如果日志里没有这条警告，别急，还有后招：

开启连接池详细日志： 在logback-spring.xml中，将HikariCP的日志级别设为DEBUG：

XML

复制

1

这样，每次getConnection()和close()都会被记录。你可以用grep "HikariCP.*getConnection\|close"来过滤日志，看是否有getConnection但没有对应的close。

检查代码中的try-with-resources： 这是Java 7引入的最佳实践。确保所有使用Connection、Statement、ResultSet的地方，都用try (Connection conn = dataSource.getConnection()) { ... }包裹。编译器会自动在}后插入conn.close()，即使发生异常也不会遗漏。我见过太多项目，还在用古老的try...catch...finally，而在finally块里忘记加if (conn != null) conn.close();，或者close()方法本身抛出SQLException，又没被处理，导致close()被跳过。

3.3 第三步：深挖根源——分析线程池与数据库配置的协同效应

有时候，泄漏的源头不在业务代码，而在基础设施的配置失配。这需要你像一个系统架构师一样，审视整个链条。

线程池与连接池的容量匹配： 这是一个经典的“木桶效应”。假设你的线程池maxPoolSize=200，而连接池maximumPoolSize=50。那么，在高并发下，最多只有50个线程能同时拿到数据库连接，其余150个线程只能在getConnection()上阻塞。这种阻塞会层层传导，最终导致Tomcat的acceptCount队列被打满，新的HTTP请求连线程都分不到，直接返回503。解决方案很简单：让连接池的容量略大于线程池。例如，maxPoolSize=200，则maximumPoolSize至少设为250。

数据库的wait_timeout与连接池的idleTimeout： 这两者必须形成“接力”。idleTimeout应该显著小于wait_timeout。例如，MySQL的wait_timeout=28800（8小时），那么HikariCP的idleTimeout就应该设为600000（10分钟）。这样，连接在池子里空闲10分钟后，就会被连接池主动关闭并移除，避免它等到数据库的8小时超时才被清理。如果idleTimeout > wait_timeout，就会出现连接池认为连接还“活着”，但数据库已经把它踢掉了，下次复用时就会报Connection closed异常。

连接池的validationTimeout与数据库的网络稳定性： 在云环境或跨机房部署时，网络可能不稳定。一个连接在池子里“睡”了5分钟，醒来时网络链路可能已经断了。此时，连接池需要在把连接借给业务线程前，先执行一个轻量级的validationQuery（如SELECT 1）来验证连接是否有效。validationTimeout就是这个验证操作的超时时间，一般设为3000（3秒）足够。如果这个值设得太小（比如100），网络抖动就会导致大量验证失败，连接被误判为失效；如果设得太大（比如30000），一次验证失败就会卡住线程30秒，造成严重延迟。

3.4 第四步：代码修复与验证——从一行close()到全链路压测

找到问题代码后，修复往往只是一行close()或一个try-with-resources。但真正的挑战在于验证修复是否彻底，以及是否会引发其他问题。

修复示例： 假设在OrderService.java第45行，你发现了这样的代码：

JAVA

复制

1

// ❌ 错误示范：没有保证close

2

Connection conn = dataSource.getConnection();

3

PreparedStatement ps = conn.prepareStatement("INSERT INTO orders ...");

4

ps.executeUpdate();

5

// 这里漏掉了 conn.close() 和 ps.close()

正确修复：

JAVA

复制

1

// ✅ 正确示范：使用try-with-resources

2

try (Connection conn = dataSource.getConnection();

3

PreparedStatement ps = conn.prepareStatement("INSERT INTO orders ...")) {

4

ps.executeUpdate();

5

} // 编译器自动插入 conn.close() 和 ps.close()

验证步骤：

本地单元测试： 写一个简单的JUnit测试，模拟高并发调用这个方法1000次，然后用HikariDataSource.getHikariPoolMXBean().getActiveConnections()检查活跃连接数是否在调用结束后回落到0。

预发环境压测： 使用JMeter或Gatling，对修复后的接口进行阶梯式压测（从10并发逐步加到1000并发），全程监控show processlist和/actuator/metrics/hikaricp.connections.*。观察active连接数是否随QPS线性增长，且在压测停止后能否在1分钟内回落。

灰度发布与观察： 将修复包发布到10%的机器上，持续观察2小时。重点看leakDetectionThreshold日志是否还有新告警，以及threadsAwaitingConnection是否归零。

实操心得：我曾经在一个支付回调接口里修复了一个泄漏，本地和预发都完美通过。但上线后，监控显示active连接数依然缓慢爬升。最后发现，是回调接口里调用了另一个第三方HTTP服务，而那个服务的SDK内部也维护了一个连接池，它的idleTimeout配置是0！这说明，连接泄漏可能存在于你依赖的任何第三方库中。所以，修复后一定要做全链路压测，不能只盯着自己的代码。

4. 高频问题与避坑指南：那些文档里不会写的血泪教训

在过去的项目里，我整理了一份“连接数失控”问题的高频问答清单。这些问题，大多来自深夜的告警电话和晨会的复盘，是无数个加班夜换来的经验结晶。

4.1 “为什么我的try-with-resources写了，但还是泄漏了？”

这是一个极其常见的陷阱。try-with-resources只保证AutoCloseable对象的close()方法被调用，但它不保证close()方法本身会成功执行。

典型场景： Connection.close()方法内部，会先尝试向数据库发送一个COM_QUIT包。如果此时网络已经中断，这个close()调用就会抛出SQLException。而这个异常，会被try-with-resources的隐式catch块捕获并吞掉，不会向上抛出。结果就是，close()调用失败了，但你的业务代码却认为“已经关闭了”，连接就这样被遗弃在池子里。

解决方案： 对于关键的、不能容忍泄漏的场景，你需要手动捕获close()异常：

JAVA

复制

1

Connection conn = null;

2

try {

3

conn = dataSource.getConnection();

4

// ... 执行业务逻辑

5

} finally {

6

if (conn != null) {

7

try {

8

conn.close();

9

} catch (SQLException e) {

10

// 记录日志，但不要抛出，避免掩盖主业务异常

11

log.error("Failed to close connection", e);

12

}

13

}

14

}

4.2 “leakDetectionThreshold设得越小越好吗？”

直觉上，设成1000（1秒）似乎能最快发现问题。但这是个危险的想法。

副作用： leakDetectionThreshold的检测机制，是在连接被借出时，启动一个后台定时任务。如果阈值设得太小，这个定时任务的创建和销毁开销会非常大，尤其是在高并发下。我曾经在一个QPS 5000的系统里，把阈值设为1000，结果发现jstat -gc显示FGC（Full GC）频率增加了3倍，因为定时任务对象的创建速度超过了GC的回收速度。

最佳实践： 阈值应该设为你的业务方法平均执行时间的2~3倍。例如，你的订单创建接口P99耗时是800ms，那就设为2000（2秒）。既能及时发现问题，又不会给系统带来额外负担。

4.3 “Druid和HikariCP，哪个更容易发生泄漏？”

这个问题没有绝对答案，但有明确的倾向性。

Druid 的优势在于监控功能极其强大，/druid/index.html页面能直观地看到每个SQL的执行次数、平均耗时、连接池状态。但它有一个历史包袱：早期版本（1.1.x之前）的removeAbandonedOnBorrow（借用时移除废弃连接）功能，如果配置不当，会误杀正在使用的连接，导致业务报错。虽然新版已废弃此功能，但很多老项目还在用。

HikariCP 的优势在于极致的性能和简洁的设计。它的代码量只有Druid的1/10，这意味着出Bug的概率更低。leakDetectionThreshold是它的原生能力，无需额外配置。但它的监控相对简单，主要靠Actuator或JMX。

我的选择： 新项目一律用HikariCP。它足够简单、足够快、足够可靠。对于老项目，如果已经在用Druid且运行稳定，没必要为了“时髦”而切换，但务必升级到最新版（1.2.x+），并关闭所有废弃的配置项。

4.4 “数据库连接池泄漏，会不会导致内存泄漏？”

会，而且是典型的“间接内存泄漏”。

原理： 一个Connection对象，内部持有一个SocketChannel，而SocketChannel又关联着一块DirectByteBuffer（堆外内存）。当Connection泄漏时，这个DirectByteBuffer就永远不会被GC回收。随着泄漏的Connection越来越多，堆外内存会持续增长，最终触发OutOfMemoryError: Direct buffer memory。

验证方法： 使用jmap -histo:live | head -20查看堆内对象，同时用jstat -gc 查看CCMG（Compressed Class Space Used）和MU（Metaspace Used）是否异常增长。但更直接的是用jcmd VM.native_memory summary，看Total: reserved=... committed=...里的committed值是否持续上涨。

终极解决方案： 根本上解决连接泄漏。堆外内存的问题，是连接泄漏的“果”，而不是“因”。

4.5 “如何预防？有没有一劳永逸的方案？”

没有一劳永逸的方案，但有一套行之有效的“防御性编程”体系：

强制Code Review： 在团队规范里明确规定，所有涉及数据库、文件、网络连接的代码，必须使用try-with-resources。PR（Pull Request）中如果没有，直接打回。

自动化扫描： 在CI/CD流水线中，集成SonarQube或Checkstyle，配置规则检查java.sql.Connection、java.io.InputStream等资源类的使用。一旦发现未关闭，构建失败。

生产环境熔断： 在连接池配置中，加入connectionInitSql: SELECT 1，并在应用启动时，用一个独立的线程，定期（比如每5分钟）执行SELECT 1来探测数据库连通性。一旦连续3次失败，就主动将连接池shutdown()，并触发告警。这能避免数据库宕机后，应用还傻乎乎地往一个“黑洞”里扔连接。

最后分享一个小技巧：在你的开发IDE（IntelliJ IDEA）里，安装一个叫Save Actions的插件。它可以配置为“在保存文件时，自动为所有new出来的Connection、Statement、ResultSet添加try-with-resources包裹”。这比任何文档和培训都管用，因为它把最佳实践，变成了你敲键盘时的肌肉记忆。

5. 工具与命令速查表：一份拿来即用的排障手册

纸上得来终觉浅，绝知此事要躬行。我把日常排查中最常用、最高效的命令和工具，浓缩成一张速查表。打印出来贴在显示器边框上，或者收藏为浏览器书签，关键时刻能救你一命。

类别

工具/命令

用途

关键参数/选项

备注

数据库诊断

show processlist;

查看MySQL当前所有会话

WHERE Command='Sleep' AND Time > 300

快速筛选出可疑的“僵尸”连接

show variables like 'max_connections';

查看MySQL最大连接数

无

确认数据库层面的瓶颈上限

show variables like 'wait_timeout';

查看MySQL连接空闲超时时间

无

与连接池idleTimeout对比

select count(*) from v$session;

Oracle查看当前会话总数

where status='INACTIVE' and last_call_et > 300

Oracle版的show processlist

Java应用诊断

jps -l

列出当前所有Java进程及其主类

无

找到你的应用PID的第一步

jstack | grep -A 10 -B 10 "getConnection"

搜索所有卡在getConnection的线程

-A 10 -B 10 显示前后10行上下文

快速定位阻塞点

jstat -gc

查看JVM GC状态

无

观察GCT（GC总耗时）是否异常高

jmap -histo:live | head -20

查看堆内对象实例数TOP20

:live 表示只统计活动对象

辅助判断是否存在内存泄漏

连接池监控

curl http://localhost:8080/actuator/metrics/hikaricp.connections.active

获取HikariCP活跃连接数

替换localhost:8080为你的应用地址

Spring Boot Actuator必须启用

jconsole

图形化JMX监控工具

启动后连接到目标Java进程

可以直观看到HikariCP的MBean属性

druid/index.html

Druid内置监控页面

访问http://your-app/druid/index.html

需在application.yml中配置druid.stat-view-servlet.enabled=true

网络与系统

netstat -anp | grep :3306 | wc -l

统计到MySQL端口（3306）的TCP连接数

:3306 替换为你的数据库端口

确认是应用层问题，还是网络层问题

ss -s

查看系统socket连接统计摘要

无

total: 12345 表示当前系统总连接数

这张表里的每一个命令，我都亲手在生产环境里敲过上百遍。它们不是花架子，而是经过千锤百炼的“瑞士军刀”。记住，最强大的工具，永远是你大脑里对系统原理的理解。命令只是你思想的延伸，当你理解了为什么jstack能抓到阻塞线程，为什么show processlist里的Time值是关键，你就不需要死记硬背这些命令，而是能根据现场情况，组合出最适合的诊断方案。

我在实际使用中发现，最常被忽略的其实是netstat和ss。有一次，我们排查一个“连接数突增”的问题，show processlist里只有20个连接，但jstack显示有200个线程在getConnection()上等待。最后用netstat -anp \| grep :3306 \| wc -l发现，系统里有150个TIME_WAIT状态的连接。原来，是数据库服务器的net.ipv4.tcp_tw_reuse内核参数没开，导致短连接频繁创建时，端口被大量TIME_WAIT占用，新的连接无法建立。这已经超出了应用层的范畴，进入了操作系统调优的领域。所以，一个合格的工程师，知识边界必须从代码，延伸到JVM，再到操作系统，最后到网络协议栈。这不是好高骛远，而是现实所迫。

这个内容后续还可以这样扩展：针对不同数据库（Oracle、达梦、PostgreSQL）的会话管理差异，写一篇《国产数据库连接泄漏排查指南》；或者，深入探讨Reactor、WebFlux这类响应式框架下，连接池的使用范式与陷阱，因为它们的线程模型和阻塞式框架完全不同。但那将是另一场硬仗了。