OpenJDK接口不返回本质是线程停住而非变慢，用jstack -l可直接定位卡点，重点关注WAITING on condition、BLOCKED on monitor entry、RUNNABLE但停留native方法三类状态，加-l才能显示锁持有者与地址。
OpenJDK 接口一直不返回，本质是线程卡在某个执行环节没退出，不是“慢”，而是“停住”。直接看 thread -b 或 jstack -l 通常就能定位到第一现场，不用先调 JVM 参数或改代码。
用 jstack -l 看线程卡在哪一行
这是最轻量、最直接的手段，不需要额外工具，JDK 自带。重点不是看全部堆栈，而是抓三个状态：
-
WAITING on condition：比如等某个锁释放、等某个 Future 完成、等数据库连接池返回连接 -
BLOCKED on monitor entry：线程想进 synchronized 方法/块，但被别的线程占着锁 -
RUNNABLE但长期停留在 native 方法里（如FileInputStream.readBytes(NativeMethod)）：大概率是 IO 阻塞（磁盘满、网络抖动、DB 连接卡住）
执行命令时加 -l 很关键，它能显示锁持有者 tid 和锁对象地址，方便交叉比对。别只跑 jstack 12345，漏掉锁信息会多绕两圈。
用 arthas thread -b 快速揪出阻塞源头
如果服务还在运行、能连上 Arthas，thread -b 是比 jstack 更聚焦的方案——它只输出当前正在阻塞其他线程的那一个线程，省去人工筛堆栈的麻烦。
- 它背后依赖的是 JVM 的
ThreadMXBean.findDeadlockedThreads()和锁监控能力，所以要求 JDK 8u60+，且未禁用-XX:+UseLockProfiler（默认开启） - 常见误判点：如果线程卡在
Unsafe.park（即Parked状态），thread -b不会报它为阻塞者，但它可能是CompletableFuture.join()或CountDownLatch.await()的等待方——这时得结合业务逻辑判断是否该等那么久 - 注意容器环境：Docker 内必须用容器内 PID（不是宿主机 PID），且 Arthas 启动用户需与 Java 进程同 UID，否则 attach 失败，报错
Unable to open socket file
排查 IO 卡点：别只盯数据库，先看连接状态
接口不返回，70% 以上最终都落在 IO 层：数据库、Redis、HTTP 调用、文件读写。但别急着查 SQL 或 redis-cli，先确认连接本身是否“活着”：
- 用
netstat -anp | grep :端口号查目标服务连接状态：大量CLOSE_WAIT表示本端没发 FIN，通常是应用层没 close socket；大量TIME_WAIT说明短连接高频发起，但未必是瓶颈；而ESTABLISHED但无数据收发，才是真卡住 - 检查连接池配置：HikariCP 的
connection-timeout默认 30s，若 DB 响应超时，线程就会卡在HikariPool.getConnection()，堆栈里能看到await或park - Java 层 HTTP 调用（如
HttpURLConnection、OkHttp）默认无超时，readTimeout和connectTimeout必须显式设，否则可能卡死几分钟甚至更久
警惕 JVM 自身卡住：GC、OOM、信号处理
线程没卡在业务代码，也可能被 JVM 暂停。这类问题往往伴随“整个服务突然无响应”，而非单个接口：
- Full GC 持续几十秒：用
jstat -gc -h10 pid 1000观察FGCT（Full GC 次数）和FGCT对应的耗时，若某次 >10s，线程全部 stop-the-world - OOM 前的假死：堆内存 98%+ 且频繁 Minor GC，但 Old 区不回收，说明对象晋升失败或存在强引用链，此时
jmap -histo可能卡住，jstack却还能出结果——这就是线索 - Linux 信号阻塞：某些国产信创环境（如 Kylin + OpenJDK 17）存在 SIGUSR2 信号被屏蔽的问题，导致
jstack、jmap等工具无法 attach，表现为“命令执行无输出”，需检查/proc/pid/status中SigBlk字段
真正难搞的不是堆栈里明明白白写着 “waiting for lock”，而是那些 RUNNABLE 却不动的 native 调用——它们藏在 JVM 底层，不暴露 Java 行号，得靠 jstack -m 把 C 堆栈打出来，再结合系统日志和 strace 判断。
