登录
首页 >  文章 >  java教程

怎么通过 IDEA 的线程转储 Thread Dump 分析程序是否假死

时间:2026-05-05 19:00:49 469浏览 收藏

小伙伴们对文章编程感兴趣吗?是否正在学习相关知识点?如果是,那么本文《怎么通过 IDEA 的线程转储 Thread Dump 分析程序是否假死》,就很适合你,本篇文章讲解的知识点主要包括。在之后的文章中也会多多分享相关知识点,希望对大家的知识积累有所帮助!

线程转储是确认IDEA中程序“假死”的最快手段,需在运行或调试状态下触发:运行时点Run窗口的Dump Threads,调试时通过Debug窗口More选Get Thread Dump;仅调试模式可捕获虚拟线程和Kotlin协程;查看dump时聚焦WAITING/TIMED_WAITING状态、主线程阻塞点及锁持有情况。

怎么通过 IDEA 的线程转储 Thread Dump 分析程序是否假死

如果程序在 IDEA 中“卡住”但 CPU 占用很低,大概率不是崩溃而是假死——线程转储是最快确认这一点的手段。它不依赖日志、不修改代码,直接抓取 JVM 当前所有线程的快照,一眼就能看出哪些线程停在哪儿、等什么、锁谁。

怎么在 IDEA 里正确触发线程转储

关键不是“点了没”,而是“点对时机和模式”:

  • 必须在程序 已启动且处于运行或调试状态 时操作;单纯编译完没运行,工具栏里根本不会出现“Dump Threads”按钮
  • 运行中卡住 → 切到 Run 工具窗口 → 点击右上角 Dump Threads(图标是两个重叠的矩形)
  • 调试中卡住 → 切到 Debug 工具窗口 → 点击 More(⋯)→ 选 Get Thread Dump
  • 如果目标进程是本地其他 Java 进程(比如 Spring Boot 打成 jar 后双击运行),得进 Profiler 选项卡找对应 PID,再点 Get Thread Dump
  • 注意:只有以调试模式(Debug)启动的进程,IDEA 才能捕获虚拟线程(Virtual Thread)和 Kotlin 协程;普通运行模式下这些信息会丢失

怎么看 dump 文件里有没有假死迹象

打开生成的 dump 文件后,不要从头读。先聚焦三个信号:

  • 搜索 java.lang.Thread.State: WAITINGjava.lang.Thread.State: TIMED_WAITING —— 这类线程没在干活,只在等;如果大量线程卡在这两种状态,且堆栈里反复出现 Object.wait()LockSupport.park()Condition.await(),基本就是假死源头
  • 看主线程(通常叫 mainForkJoinPool.commonPool-worker-*)是否卡在 sun.misc.Unsafe.parkjava.awt.EventDispatchThread.pumpOneEventForFilters —— 前者常见于自定义线程池饥饿,后者说明 Swing/AWT UI 线程被阻塞
  • 检查是否有线程长时间持有锁却不再推进:找 - locked <0x...> 行,再顺着往上翻几行看它最后执行的是哪行业务代码;如果那行是数据库查询、HTTP 调用、文件读写,而后续没任何日志输出,大概率是外部依赖超时未设或失败未处理

jstack 和 IDEA dump 的结果为什么有时对不上

不是你眼花了,是底层机制不同:

  • jstack -l 输出的是 JVM 原生视角,包含锁的内存地址(如 <0x0000000712345678>)、线程优先级、是否为守护线程等细节,但不识别 Kotlin 协程或虚拟线程语义
  • IDEA 的 dump 是在 JVM 级别之上加了一层解析:它能把 ContinuationVirtualThreadCoroutine 标出来,并把协程挂起点映射回 Kotlin 源码行号;但代价是部分锁信息可能被简化或合并
  • 最常踩的坑:jstack 显示某线程在等 ReentrantLock$NonfairSync.acquire,而 IDEA dump 里只写 parking to wait for <0x...> —— 这不是 bug,是 IDEA 默认折叠了 JDK 内部栈帧;需要手动展开或切到 “Raw” 视图才能看到全貌
  • 生产环境排查建议:优先用 jstack -l ,因为稳定、无侵入;IDEA dump 更适合开发阶段快速验证逻辑阻塞点

假死 ≠ 死锁,但 dump 里容易漏掉这个关键线索

很多人盯着 deadlock 关键字找,结果一无所获——因为假死更多是单点阻塞,不是循环等待:

  • 比如一个线程调用了 HttpClient.execute(),但服务端一直不返回,它就永远停在 SocketInputStream.socketRead0,状态是 RUNNABLE(不是 WAITING),CPU 占用反而可能飙高;这种得结合 top -H -p 看具体线程的 %CPU
  • 又比如使用了 CompletableFuture.join() 但上游 Future 没完成,线程卡在 WaitNode.wait(),dump 里显示 WAITING,但没锁竞争,IDEA 也不会标为 deadlock
  • 最容易被忽略的是:某些框架(如早期 Spring Cloud LoadBalancer)会在初始化时同步拉取服务列表,若注册中心不可达,主线程就卡在 DNS 解析或 connect timeout 前,dump 里只看到 java.net.Inet6AddressImpl.lookupAllHostAddr —— 这种必须配合网络诊断,不能只靠 dump

理论要掌握,实操不能落!以上关于《怎么通过 IDEA 的线程转储 Thread Dump 分析程序是否假死》的详细介绍,大家都掌握了吧!如果想要继续提升自己的能力,那么就来关注golang学习网公众号吧!

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>