如何通过 jstack 转储中的 Native 状态快速排查由于 JNI 调用导致的进程挂死异常-java教程-PHP中文网

Native状态在jstack中表现为java.lang.Thread.State: RUNNABLE但栈帧含Native Method（如Unsafe.park、Object.wait或自定义JNI函数），需加-e参数才能显示完整本地调用栈，否则无法定位C/C++层阻塞点。

如何通过 jstack 转储中的 native 状态快速排查由于 jni 调用导致的进程挂死异常

Native 状态在 jstack 输出里长什么样

当你看到线程堆栈里出现 java.lang.Thread.State: RUNNABLE，但紧接着的栈帧全是 at sun.misc.Unsafe.park(Native Method)、at java.lang.Object.wait(Native Method) 或更关键的 at com.example.NativeLib.doWork(Native Method)，这就表明线程已进入 JNI 层——jstack 只能显示“卡在 native”，无法展开 C/C++ 代码逻辑。

这类线程不会标为 BLOCKED 或 WAITING，而是保持 RUNNABLE 状态却长时间无进展，是 JNI 挂死最典型的表征。尤其注意那些 nid（本地线程 ID）在 top -H -p 中 CPU 占用持续接近 100% 的线程，它们很可能正陷在某个死循环或阻塞式系统调用里。

jstack -e 是唯一能暴露 JNI 上下文的关键参数

默认 jstack 不显示 native 帧，你只会看到 Native Method 这一行，毫无细节。必须加 -e（JDK 8u60+ 支持）才能导出完整的本地调用栈：

jstack -e 12345 > thread_dump_native.log

输出中会出现类似这样的帧：

at com.example.NativeLib.processData(Native Method)
- locked  (a java.lang.Object)
at com.example.Service.handleRequest(Service.java:89)
...

如果 -e 输出里某线程的 native 帧停在：pthread_cond_wait、read、sem_wait、epoll_wait 或自定义函数名（如 libmycrypto.so::encrypt_loop），基本可锁定问题发生在 native 层等待资源或逻辑卡死。

cn-json-diff

比较两个 JSON 文件并显示差异。支持嵌套结构、数组及值变更。纯 Python 标准库实现，无需 API 密钥。

下载

没加 -e 就分析 native 问题，等于蒙眼找钉子
容器环境若报 Unable to get pid of LinuxThreads manager thread，先试 jstack -F -e （需 root）
-e 会略微增加 dump 开销，但线上紧急排查值得

如何确认是 JNI 导致的挂死而非 Java 层阻塞

区分关键点在于锁持有关系和线程行为模式：

Java 层 BLOCKED 线程一定在等某个 locked 地址，且多个线程会争抢同一把锁；JNI 挂死线程通常不显示锁信息，或只显示它自己持有的对象锁（无关紧要）
运行 jstack -l | grep -A 5 "Found one Java-level deadlock"，若无输出，说明 JVM 没检测到 Java 锁死锁，问题大概率在外
对比 jstat -gc 1000：若 GC 频率正常（YGC/FGC 很低），但应用完全无响应，JNI 挂死概率陡增
用 strace -p （tid 是 nid 转十进制）直接跟踪该 native 线程的系统调用，看是否卡在 futex、recvfrom 等上

Docker/K8s 环境下 jstack -e 失效的绕过方案

容器中常因权限、cgroup 或 PID namespace 隔离导致 jstack -e 失败，典型错误包括 Can't attach to process 或只输出 Signal Dispatcher 等少量线程。

此时不要硬刚 attach，改用 JVM 自身能力：

向 Java 进程发 kill -3 ，JVM 会将完整线程 dump（含 -e 级别 native 帧）打印到 stdout/stderr——前提是启动时没重定向掉日志，且未禁用 -XX:+PrintGCDetails 类参数干扰输出位置
若日志被重定向，可在容器内执行：echo 'jstack -e ' | jcmd VM.native_memory summary（部分 JDK 版本支持 jcmd 替代）
终极手段：进容器后用 gdb -p + thread apply all bt，直接看 native 线程 C 栈（需容器装 gdb、debuginfo 包）

native 层没有栈帧符号时，addr2line -e libxxx.so 0xabc123 是唯一能定位到 C 源码行的办法——所以上线前务必保留 .so 的 debug 符号文件。