线上出故障的时候最怕的不是问题本身而是大家围在屏幕前七嘴八舌最后用错误的方式抓了一堆没用的现场数据诊断方向完全跑偏。尤其是“线程 Dump”和“Heap Dump”这两个东西名字长得像很多人以为差不多关键时刻抓错了不仅浪费宝贵的故障定位窗口严重时还会把服务直接搞崩。这篇就把两者的区别、适用场景、抓取时机讲透看完你就知道线上出问题时手里该先拿哪把刀。1. 先判断故障类型再决定抓哪个 Dump1.1 线上故障场景其实就那几类我做了这么久后端和运维线上告警五花八门但归纳下来核心就这几类CPU 使用率突然打满、请求 RT 飙升或大量超时、服务假死端口还在但请求不响应、内存持续增长最后 OOM以及线程池队列堆满导致的任务拒绝。不同类型的故障对应需要采集的现场数据是完全不同的。CPU 飙高通常意味着有线程在疯狂运算或频繁 GC这时候线程 Dump 是最直接的证据。而内存持续增长直到溢出你必须拿到堆内存的快照才能分析出到底是谁占着内存不释放。服务假死则往往和线程阻塞、死锁或者数据库连接池耗尽有关这类问题线程 Dump 更有效。很多人出错的地方在于一看到服务卡顿就直接去抓 Heap Dump结果 Dump 文件几个 GB光下载到本地分析就得半小时最后发现堆内存一切正常完全没抓到重点。因为没有搞清楚“卡”到底是 CPU 忙不过来还是线程在等待资源还是内存不够导致频繁 GC。1.2 一句话判断原则线程问题抓线程 Dump内存问题抓 Heap Dump用一个最直观的判断标准来区分如果你的故障表象是CPU 高、响应慢、死锁、线程阻塞那么主要抓线程 Dump如果你的故障表象是内存持续增长、OOM、频繁 Full GC 后内存仍回收不了那么主要抓 Heap Dump。这里要说清楚一个容易混淆的点内存问题也会导致 CPU 高。因为当堆内存快满时JVM 会不断尝试 GCGC 本身非常消耗 CPU。但这种 CPU 高通常伴随明显的 GC 日志特征比如 Full GC 频繁且每次回收后内存占用下降不明显。这时候要不要抓线程 Dump也可以抓但抓到的线程堆栈大概率只能看到 GC 线程在活动业务线程都在等待这并不能帮你找到内存泄漏的根源最终还是得靠 Heap Dump 来分析对象引用链。所以核心逻辑是反过来的根据故障的第一表象判断问题域再选择对应类型的 Dump 文件。抓错了方向等于白抓而且大 Dump 文件抓取时的停顿可能会加重故障。2. 线程 Dump 实操5分钟定位线程卡死和 CPU 飙升2.1 线程 Dump 怎么抓常用命令和工具线程 Dump 本质上是 JVM 中所有线程在当前时刻的执行快照包含每个线程的栈信息、锁状态、线程状态等。它反映的是“此刻所有线程在干什么”是定位线程级问题最直接的证据。最通用的命令是jstackJDK 自带用法极其简单jstack -l pid thread_dump.txt-l参数会额外输出锁的持有和等待信息排查死锁时务必带上。除了 jstack还有几种抓取方式值得掌握kill -3 pid向 JVM 进程发送 SIGQUIT 信号JVM 会将线程 Dump 输出到标准输出通常是应用的日志文件。这个方式的优势是不需要额外权限也不需要进入容器适合只给了应用部署权限的运维场景。Arthas 的thread命令thread -n 3可以直接打印 CPU 占用最高的 3 个线程thread -b可以定位死锁阻塞的线程调试时比 jstack 更直观。jcmd pid Thread.print比 jstack 更“正统”的官方推荐命令输出格式基本一致。抓取时有个重要技巧线程 Dump 应该连续抓多次间隔 3 到 5 秒至少抓 3 份。单份 Dump 只能说明那一刻的线程状态可能带有偶然性。比如某个线程恰好在那瞬间执行完一次耗时操作单份 Dump 里看起来一切正常。但如果你连续抓 3 份发现同一个线程总是停留在同一个方法栈上那这个线程卡住的证据就非常扎实了。我一般建议第 1 份看整体状态第 2 份和第 3 份对比找出“始终如一的那个栈”这才是真正的问题线索。2.2 线程状态解读RUNNABLE、BLOCKED、WAITING 到底代表什么拿到线程 Dump 后最关键的就是识别线程状态。JVM 中的线程状态主要有 NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED 这几种。很多人看到 RUNNABLE 就以为线程正常其实这是个常见误区。RUNNABLE 只表示线程“可以运行”不代表它“没有在干活”。当 CPU 飙高时你会看到大量业务线程处于 RUNNABLE 状态但它们的堆栈都停留在同一个方法上比如正则匹配、序列化、循环计算这时候就说明热点在这里。BLOCKED 状态表示线程在等待获取一个被其他线程持有的锁典型的锁竞争问题。当大量线程 BLOCKED 且都在等待同一个锁对象时几乎可以断定有锁冲突或者死锁风险。WAITING 和 TIMED_WAITING 表示线程在等待其他线程的通知或等待一段时间常见于Object.wait()、Thread.join()、LockSupport.park()等线程池中的空闲线程也经常处于这种状态需要结合堆栈上下文来判断是否正常。另外一个非常实用的定位技巧是抓取前先记录 CPU 高的线程 ID。用top -Hp pid按 CPU 降序排列找到排名靠前的线程 ID十进制然后转换成十六进制去线程 Dump 中搜索这个 ID。因为 jstack 输出的线程 ID 是十六进制的转换关系要对得上才能准确找到“到底谁在烧 CPU”。这个操作看起来简单但很多人第一次操作往往会转错进制建议用printf %x\n pid来做转换一次到位。2.3 怎么快速定位问题线程一份 Dump 的阅读顺序线程 Dump 文件通常几百 KB 甚至几 MB包含几百个线程逐行看肯定不现实。我的习惯是有一套固定的阅读顺序第一步先看有没有Deadlock字样。JVM 做线程 Dump 时会自动检测死锁如果文件末尾出现了死锁提示直接把相关的线程栈拿出来分析即可。第二步筛选状态异常的线程。BLOCKED优先看因为阻塞通常意味着锁竞争WAITING要看具体等待在什么对象上RUNNABLE则重点关注它的栈顶方法是什么。第三步找到与你业务相关的线程组。比如 Tomcat 的http-nio-开头的线程、Dubbo 的DubboServerHandler线程集中在这些线程上分析。如果业务线程几乎全部处于 WAITING 状态且都在等待同一个锁那基本可以确认是资源竞争问题。第四步结合多次 Dump 对比找出那些“每次都在同一个位置”的线程。这需要一点耐心我通常会写一个简单的脚本把多次 Dump 中每个线程的栈顶方法提取出来对比重复出现的栈问题通常会自己浮出水面。3. Heap Dump 实操让内存泄漏无处遁形3.1 Heap Dump 怎么抓jmap、Arthas 和 OOM 自动导出Heap Dump 是 JVM 堆内存的全量快照记录了所有存活对象、对象之间的引用关系、类加载信息等。分析堆 Dump 是排查内存泄漏时最有效的手段但它的抓取代价比线程 Dump 大得多。默认情况下jmap -dump:live,formatb,fileheap.hprof pid会触发一次 Full GC将堆中所有对象序列化到文件这个过程会造成 STWStop The World暂停。线上环境抓 Heap Dump 前必须评估影响。如果堆内存已经占用很大比如 8GB 的堆Dump 文件可能超过 8GB抓取过程可能持续几十秒甚至几分钟期间服务完全不可用。所以我的建议是尽量在业务低峰期抓取或者优先考虑使用 OOM 时自动导出的机制。JVM 提供了非常实用的启动参数-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/heapdump/加上这两个参数后JVM 抛出OutOfMemoryError时会在指定的路径自动生成堆快照这个机制是线上环境最可靠的兜底手段。它不像手动 jmap 需要你守在机器前而且 OOM 发生时 JVM 本身已经处于极度饥饿状态再手动执行 jmap 成功率很低。所以建议所有 Java 服务都默认开启这个参数成本几乎为零收益却非常大。除了 jmapArthas 的heapdump命令、JVisualVM 的导出功能也都能生成堆 Dump。Arthas 适合已经进去调试的场景不需要额外开端口JVisualVM 适合本地开发排查。但要说最稳定、最官方的方式还是 jmap 和 OOM 自动导出。3.2 分析工具与步骤MAT 的 Leak Suspects 和 Dominator Tree拿到 Heap Dump 后推荐使用 Eclipse MATMemory Analyzer来分析它是目前堆 Dump 分析领域的事实标准。第一次打开大文件时 MAT 会问你要不要生成报告直接选择生成 Leak Suspects Report它是 MAT 的自动分析结果会列出最可能的内存泄漏点。但“自动分析”不等于“一定准确”。实际使用中我发现MAT 的 Leak Suspects 经常会报出一些其实并不泄漏的模式比如缓存、Spring 单例持有的对象被误报。所以我通常会结合两个视图交叉验证Histogram直方图按类统计实例数量和占用空间。先看哪些类的实例数异常多。例如byte[]占用巨大说明有比较大的缓冲数据一个自定义的业务对象实例数高达几十万那问题基本就锁定了。Dominator Tree支配树展示对象之间的持有关系帮你找到“谁在引用这个对象”。从怀疑对象出发沿着支配树向上找 GC Roots 的引用链就能定位到真正持有没有释放的上层对象。比如有一次排查线上内存泄漏Histogram 里看到java.lang.String实例数量高达几百万但 String 是基础类型到处都是光看它没有意义。于是我在 Dominator Tree 里展开发现大量 String 都被一个ConcurrentHashMap持有而它的 key 是用户 ID 对应的缓存数据。追溯代码后确认是某次发版时把缓存清理逻辑注释掉了导致缓存只增不减。这就是 Heap Dump 分析的标准思路从大对象入手沿引用链回溯到业务持有者。3.3 线程 Dump 和 Heap Dump 一起看效率更高这里我想多说一句。虽然前面强调“先判断故障类型再决定抓哪个”但实际处理复杂故障时两个 Dump 配合使用往往能起到 112 的效果。举例来说服务频繁卡顿且伴随 OOM。单独分析 Heap Dump 可能只看到内存里有大量未释放的对象但说不清这些对象为什么没被释放。这时抓一份线程 Dump如果发现大量线程阻塞在某个队列的put()方法上且队列已满就能理解问题全貌生产者线程不间断地向队列写入数据而消费者线程因为外部依赖超时而卡住队列越积越多最终撑爆堆内存。线程 Dump 给出了“谁在等待”Heap Dump 给出了“什么占满了内存”两者组合起来才能还原完整的事故现场。所以“先抓哪个”这个问题更深层的答案是以主线判断为主以双份采集兜底。如果条件允许且影响可控建议两个 Dump 都抓但时序上有讲究——先抓线程 Dump代价小、秒级完成再抓 Heap Dump代价大、需要慎重因为线程 Dump 抓取几乎不影响业务可以先“快照”住线程状态后续再根据初步分析决定要不要抓重的 Heap Dump。4. 抓取顺序的决策逻辑与配套参数建议4.1 为什么线上优先考虑线程 Dump这个问题从我带团队以来被问过很多次。我给出的建议始终是没有明确迹象表明是内存问题时优先抓线程 Dump。理由之一是线程 Dump 的抓取成本极低。jstack 本身对 JVM 的影响微乎其微不触发 GC、不暂停业务线程哪怕在用户高并发访问时执行也基本无感。而 Heap Dump 动辄几个 GB抓取时会暂停应用还会占用大量磁盘 IO运行时越长、堆越大影响越明显。理由之二是线程 Dump 能覆盖更多故障场景。CPU 高、请求超时、死锁、线程池拒绝甚至是外部依赖抖动导致的线程阻塞都能在线程 Dump 里找到线索。而 Heap Dump 只对内存问题敏感对 CPU 高和死锁几乎没有直接帮助。理由之三是排查效率。线程 Dump 文件通常几百 KB下载分析也就几十秒Heap Dump 可能几 GB光从服务器传到本地分析环境就要很长时间。故障排查讲究快线上每一分钟都在流失用户和订单连现场都不可能下载分析工具再强大也帮不上忙。当然如果系统已经在告警“堆内存使用率超过 95%”或者已经发生了 OOM那就不用犹豫直接抓 Heap Dump 或者捞 OOM 自动导出的文件。这两种情况属于问题域非常明确不需要先试探。4.2 推荐预设的 JVM 启动参数组合实战经验告诉我与其故障发生时手忙脚乱地敲命令不如在服务上线前就把参数配置好。下面这套是我在实际项目中常用的一组参数兼顾了故障现场的自动留存和问题分析-Xms4g -Xmx4g -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/heapdump -XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/data/logs/gc.log几个参数的意义分别说一下。-Xms4g -Xmx4g将初始堆和最大堆设为相同值避免 JVM 动态扩缩容带来的性能和不确定性。HeapDumpOnOutOfMemoryError前面已经解释过是 OOM 时的自动兜底。GC 日志参数则用于分析内存问题时的辅助证据比如 Full GC 的频率、每次回收后的剩余空间这些数据和 Heap Dump 配合起来才能完整还原内存使用的时间线。有个细节容易被忽略HeapDumpPath指向的目录要提前创建并且要确认 JVM 进程对它有写权限不然 OOM 发生时 Dump 文件生成失败到时候整个团队对着日志看半天也不知道为什么没产出堆快照。另外磁盘空间也要留足Heap Dump 文件大小约等于堆大小一个 4GB 堆产生的 Dump 文件可能接近 4GB目录所在分区至少要有 1.5 倍的堆大小空闲空间才稳妥。4.3 大内存机器和小内存机器的抓取策略差异不同规格的机器抓取策略差异很大。对于堆内存 2GB 以内的小服务jmap 抓取 Heap Dump 通常只暂停几秒到十几秒影响相对可控手动抓取问题不大。但对于 16GB 甚至 32GB 堆的大型服务jmap 触发 Full GC 并导出完整堆快照进程可能 hang 住几十秒这个停顿在核心链路上是不可接受的。处理大堆服务时我常用的办法是优先使用 OOM 自动导出机制平时不手动抓全量 Heap Dump需要手动分析时可以用jmap -histo:live pid先获取存活对象的直方图这个操作虽然也会触发 Full GC但产出的是文本统计文件小、传输快大致能判断出哪些类型的对象异常多。经过这一步筛选后如果还需要精细化定位引用链再找低峰期窗口或者通过容器水平扩展剥离单台流量后进行抓取。另外现在很多服务跑在 Kubernetes 里宿主机上直接执行 jstack 或 jmap 经常会报Unable to open socket file之类的错误这与容器 PID namespace 隔离有关。这种情况下要么通过kubectl exec进入容器内执行命令要么开启 JMX 远程连接再通过 JVisualVM 抓取。我更推荐前者因为 JMX 远程暴露在公网上本身就是个安全隐患。5. 高危提醒Heap Dump 里的敏感信息与安全防护5.1 一个真实的高危现场好不容易抓到的 Dump 变成了“脱裤”入口这个话题可能超出很多开发者的日常关注范围但近两年的攻防演练和高危漏洞报告中Heap Dump 已经成了一个被频繁利用的攻击面。起因是很多 Java 框架和应用会把敏感信息放在内存中数据库连接串带着账号密码、Redis 密码、加密密钥、用户 Token、支付回调密钥等等。而 Heap Dump 是堆内存的全量快照这些敏感信息会原封不动地躺在里面。如果你能拿到一个应用的 Heap Dump 文件就可以用 MAT 或者 JDK 自带的jhat工具直接浏览堆里的对象内容把内存中的密码、Token 一个个捞出来。我记得很清楚有一次自查内部系统时随便拉了一个服务的 Heap Dump在 MAT 的 OQL 里执行一句简单的查询SELECT toString(s.value) FROM java.lang.String s WHERE toString(s.value) LIKE %password%结果瞬间捞出了十几个包含 “password” 字符串的对象数据库密码、阿里云 AccessKey、内部 API 密钥全在里面。当时我就冒了一身冷汗如果这个文件被攻击者拿到整个内网基本等于裸奔。5.2 Heap Dump 文件是如何泄露出去的Heap Dump 文件泄露的常见路径主要有这么几条。第一条是 HeamDump 被写到 Web 应用的静态目录或可下载目录。有些团队为了分析方便会把 Dump 文件存放在应用的工作目录下而这个目录恰好是 Tomcat 的 Web 根目录或能被 URL 直接访问的路径。攻击者只需要猜测文件名并构造下载请求就能把整个堆快照拖走。第二条是 Spring Boot Actuator 暴露了 heapdump 端点这个问题在 CVE 相关安全公告里多次出现。Actuator 的/actuator/heapdump端点原本用于运维管理如果未做权限控制并暴露到公网任何人都可以通过一次简单的 HTTP GET 请求拿到 JVM 的堆 Dump。第三条是 Dump 文件通过日志转储、错误上报系统等被带到仓库或第三方平台。比如有人把 Dump 文件直接上传到 Git 仓库或者通过 IM 群发给同事排查然后链接外泄。这些看起来是内部行为但一旦文件流出去里面的敏感数据就一览无余。5.3 安全红线与避免裸奔的几条硬措施针对这个风险我建议每个 Java 服务都必须做几件事。一是关闭或加固 Actuator 的 heapdump 端点。如果不需要远程 dump直接把端点关掉management.endpoint.heapdump.enabledfalse如果确实需要保留就必须做严格的网络访问控制比如只允许运维网段访问并叠加 Spring Security 认证。二是Dump 文件落到专用受控目录并定期清理。不要放到 Web 可访问目录不要放在应用当前目录建议放到/data/logs/heapdump这样的独立目录目录权限设为仅运维用户可读写文件生成后通过安全通道比如内部堡垒机的文件传输拉取分析完成后立即删除。我见过很多事故都是“生成了 Dump 却忘了删”最后被扫描器扫到。三是对核心密钥做运行时脱敏。密码、Token 这类信息尽量不直接在内存中长期保存。比如数据库密码可以使用配置中心动态获取使用后及时清理加密密钥可以放到专用的密钥管理服务中通过 JNI 或网关方式调用避免在主应用堆内存中出现明文。四是有条件的话对 Dump 文件进行加密存储。虽然加密加大了分析时的工作量但相比泄露后账号密码被拖库的损失这点成本完全值得。安全团队如果审计严格这一步往往是必需项。这里的核心观点是Heap Dump 既是排查内存问题的最好武器也是攻击者眼中的“信息金矿”。每个上线的服务都应该在预案里写清楚 Dump 文件的产生、存储、传输、销毁全流程而不是抓完就丢在那里不管。6. 常见问题与排查技巧实录6.1 抓 Dump 导致应用更卡甚至重启怎么办这个问题在手动抓 Heap Dump 时经常出现最大的原因是抓取过程触发了 Full GC再加上导出大量堆数据带来的 IO 压力对原本已经高负载的服务来说可能就是压死骆驼的最后一根稻草。应对办法一是推广 OOM 自动导出机制让 JVM 自己决定抓取时机二是确实需要手动抓取时优先选择业务低峰期并先确认堆内存占用率如果使用率已经超过 90%抓取风险很大先把部分流量切走再操作三是测试环境提前演练用压测确认一下你们的应用在特定堆大小下 jmap 抓取到底要暂停多久形成一份记录这样线上决策时心里有底。线程 Dump 抓取一般不会导致服务卡顿但有一种例外如果系统本身线程数已经逼近系统上限比如 Linux 下单进程线程数限制执行 jstack 时 JVM 分身线程也创建失败可能会看到java.lang.OutOfMemoryError: unable to create native thread。这种情况先检查ulimit -u和pthread限制把线程数降下来才是根本。6.2 jstack 或者 jmap 命令报错连不上进程在容器化、虚拟化环境里jstack 和 jmap 连不上进程是非常常见的报错典型提示包括Unable to open socket file、process not found、well-known file is not secure。出现这类报错大部分情况是 JVM 进程运行时使用了一个临时目录存放 attach 所需的 socket 文件而这个目录在容器环境下不可见或者权限不匹配。解决办法是给 JVM 增加参数-Djava.io.tmpdir/path/to/writable/tmp确保目录存在且用户可写。如果服务部署在容器里更直接的方式是进入容器所在 PID namespace 再执行命令或者直接在 Dockerfile 里提前安装 JDK 调试工具。另外有个小坑要提醒如果你在生产环境用的 JRE没有 jmap、jstack 命令可以临时使用jcmd替代它是 JDK 自带工具功能覆盖了 jstack 和 jmap 的大部分场景。如果 JRE 连 jcmd 都没有就只能在服务启动时加上 JMX 远程开关但一定记得设置强密码和限定来源 IP。6.3 Dump 文件太大本地 MAT 直接打不开内存 8GB 以上的服务Heap Dump 文件经常超过 8GB普通笔记本电脑用 MAT 打开简直就是灾难不是报Java heap space就是卡死到怀疑人生。解决思路有几个方向一是用 MAT 的ParseHeapDump.sh脚本在服务器上先做初步解析生成报告和索引再只把索引拉回本地查看二是给 MAT 加大内存编辑MemoryAnalyzer.ini把-Xmx调到比 Dump 文件大小更大才有得玩比如 12GB 的 Dump 就设-Xmx12g三是用阿里开源的 Arthas 结合heapdump在服务器端做对象直方图分析不走本地传输。我自己的习惯是服务器上先用jmap -histo:live看一眼大对象分布如果这一步就能定位到问题就最好省去下载大文件的痛苦如果定位不了再考虑拉 Dump 文件到专门的排查机器分析。毕竟 Dump 文件动辄几 GB传输时间和本地分析内存都是成本。6.4 线上故障现场快速排查参考表最后把常用的决策逻辑整理成一张速查表直接照着做就行故障现象首要抓取动作辅助动作预期定位CPU 飙高业务无超时连续抓 3 份线程 Dump间隔 3 秒top -Hp记录高 CPU 线程 ID热点方法、死循环、GC 线程异常CPU 飙高 频繁 Full GC抓线程 Dump 查看 GC 日志条件允许时抓 Heap DumpGC 回收效率、堆内存占满服务假死请求无响应连续抓 3 份线程 Dumpnetstat查看连接状态线程池耗尽、数据库连接池阻塞、死锁接口 RT 持续上升抓线程 Dump查看外部依赖超时配置外部服务慢、锁等待内存使用率稳步上升抓 Heap Dump 或启用 OOM 自动导出查看 GC 日志中 Full GC 频率内存泄漏、集合无限增长已经 OOM 或进程重启找 OOM 自动导出的 Heap Dump查看启动日志和 GC 日志泄漏根因、GC Roots 引用链Spring Boot 项目线程 Dump 用 Arthasthread检查 Actuator 端点暴露情况是否存在 heapdump 泄露风险在实际排查中我也经常遇到一种情况分析半天发现线程 Dump 里根本没有异常Heap Dump 里内存也很健康最后定位到是数据库慢查询拖垮了整个接口。所以 Dump 只是工具排查问题还是要以整体视角去看连接池状态、外部依赖监控、链路追踪数据这些都不能缺席。但反过来如果没有 Dump 文件这类基础现场数据很多问题根本无从下手。我个人在实际操作中的体会是线上故障处理最忌讳“一根筋”。不要死守“先线程后堆”的顺序也不要因为 Dump 文件大就放弃采集。判断完整体故障域之后能小代价采集现场就立刻采集不能小代价采集就依赖自动机制之后交叉分析各类信息。多经历几次真实故障后你会发现所谓“抓哪个”并不只是一个技术选型问题更是对整个系统运行状况理解深度的一次检验。希望这篇经验总结能帮你在下一次线上告警来临的时候少一分慌乱多一分从容。