java应用中连接池线程被数据库网络阻塞挂起，本质是socket i/o层阻塞（如socketinputstream.read），导致线程长期waiting/timed_waiting；需通过线程栈、网络链路、连接池参数和数据库侧四方面交叉排查。
Java 应用中连接池线程被数据库网络阻塞挂起，本质是连接获取或执行 SQL 时卡在 Socket I/O 层（如 SocketInputStream.read、NioSocketChannel.doReadBytes），导致线程长期 WAITING 或 TIMED_WAITING，进而引发请求堆积、超时、CPU 空转等现象。排查需从线程状态、网络链路、连接池配置和数据库侧四方面交叉验证。
看线程栈：确认是否真卡在网络读写
用 jstack -l <pid></pid> 抓取线程快照，重点搜索连接池相关线程（如 HikariCP 的 HikariPool-1 housekeeper、Druid 的 Druid-ConnectionPool-Create-XXXX）以及业务线程中调用 getConnection() 或 executeQuery() 的堆栈：
- 若看到
at java.base/java.net.SocketInputStream.socketRead0(Native Method)或at java.base/sun.nio.ch.NioSocketPipe$SinkChannelImpl.write(NioSocketPipe.java:...)，基本确定卡在 TCP 接收/发送缓冲区，等待 DB 返回数据或 ACK； - 若卡在
com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:...)且等待notEmpty.awaitNanos()，说明连接池已空，但根源可能是已有连接被网络阻塞未归还； - 注意区分「连接获取阻塞」和「SQL 执行阻塞」：前者常因连接泄漏或 maxPoolSize 过小；后者更可能是网络或 DB 响应慢。
查网络链路：定位中间环节异常
网络阻塞不一定是数据库本身问题，常见于中间设备：
- 用
telnet <db-host><port></port></db-host>或nc -zv <db-host><port></port></db-host>验证基础连通性； - 抓包分析：
tcpdump -i any host <db-ip> and port <db-port> -w db.pcap</db-port></db-ip>，打开 Wireshark 查看是否有大量重传（Retransmission）、零窗口（ZeroWindow）、TCP Keep-Alive 超时或 FIN/RST 异常； - 检查防火墙、SLB（如 AWS ALB/NLB、阿里云 SLB）、ProxySQL 等是否启用了连接空闲超时（idle timeout），且该值小于应用连接池的
connection-timeout或 DB 的wait_timeout，导致中间设备单方面断连而应用无感知； - 确认 DNS 解析是否稳定（尤其使用域名连接时），可临时改用 IP 测试排除解析延迟或失败。
调连接池参数：暴露问题并缓解影响
合理设置超时与检测机制，避免线程无限等待：
-
HikariCP：启用
connection-timeout（建议 30s）、validation-timeout（5s）、leak-detection-threshold（如 60000ms，查连接泄漏）；开启keepalive-time（需 DB 支持）和socket-timeout（MySQL 驱动 8.0+ 支持socketTimeout参数）； -
Druid：设置
maxWait、timeBetweenEvictionRunsMillis、minEvictableIdleTimeMillis，并开启testWhileIdle+validationQuery； - 统一建议：关闭自动重连（如 MySQL 的
autoReconnect=true），它会掩盖真实故障；驱动升级到最新稳定版（如 MySQL Connector/J 8.0.33+），修复旧版 socket 超时失效 bug。
查数据库侧：确认服务端是否健康
DB 端响应慢或连接异常也会传导为网络阻塞：
- 登录 DB，查当前连接数：
show status like 'Threads_connected';是否接近max_connections； - 查慢查询和长事务：
show full processlist;看是否有State = "Sending data"、"Locked"或运行时间过长的Query； - 检查 DB 主机资源：CPU、内存、磁盘 I/O（
iostat -x 1）、网络丢包（ping -c 10 <app-host></app-host>）； - 确认 DB 的
wait_timeout和interactive_timeout（MySQL）是否远小于连接池的空闲回收时间，导致连接被服务端主动断开，而客户端仍尝试复用。
不复杂但容易忽略：多数“网络阻塞”实际是连接未正确关闭（Statement/ResultSet 未 close）、连接池配置与 DB 超时不匹配、或中间网络设备静默断连。先抓线程栈定性，再结合网络和 DB 日志定量，比盲目调大超时更有效。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
