文章目录 01 JVM 监控与诊断工具地图️ 02 CLI 命令行工具轻量、无 GUI 依赖 2.1 基础诊断“四大天王”1. jps (JVM Process Status Tool)2. jstat (JVM Statistics Monitoring Tool)3. jmap (Memory Map for Java)4. jstack (Stack Trace for Java) 2.2 万能集成命令 (jcmd) 03 图形化/监控诊断工具GUI 与离线分析 3.1 经典可视化面板1. JConsole (Java Monitoring and Management Console)2. VisualVM (All-in-One GUI) 3.2 飞行记录仪与低消耗诊断JMC (Java Mission Control) JFR (Java Flight Recorder) 3.3 堆转储分析神器MAT (Eclipse Memory Analyzer Tool) 3.4 线上零侵入动态诊断Arthas (阿里开源 Java 诊断利器)⚙️ 04 工具选型对比与真实工业场景 4.1 全景选型对比表 4.2 真实工业场景对照表 05 生产排查标准流程 06 如何记住具体的使用场景1. 场景化记忆法把 10 个工具压缩成 3 个角色2. 故障诊断决策树面对问题的反射弧3. 黄金速记口诀四句顺口溜4. 主动检索自测卡片检验记忆 07 真实生产排查实战案例️ 项目背景与 JVM 诊断体系 案例 1高峰期绑卡 core 接口 CPU 100% 伴随频繁 Full GC 诊断1. 故障现象2. 排查过程top jstat Arthas3. 根因与优化重构 案例 2一键绑卡鉴权链路 ThreadLocal 慢速 OOM 内存泄漏剖析1. 故障现象2. 排查过程jstat heapdump MAT3. 根因与防重解决️ 生产排查与架构调优选型对照表 01 JVM 监控与诊断工具地图JVM 诊断工具围绕“进程定位 - 状态监控 - 内存/线程导出 - 离线/实时分析”四步建立。工具的使用场景完全取决于运行环境的限制条件GUI 依赖、安全权限、性能损耗承受度。[ JVM 诊断工具阵营 ] │ ┌───────────────────────────────────┼───────────────────────────────────┐ ▼ ▼ ▼ 【CLI 命令行阵营】 【GUI / 离线分析】 【线上诊断神器】 轻量级、原生自带 图形化、大 Dump 离线分析 零侵入、实时热查 • jps (Process Status) • JConsole (JMX Console) • Arthas (阿里开源) • jstat (Statistics) • VisualVM (All-in-One) • jmap (Memory Map) • JMC (Mission Control) • jstack(Stack Trace) • MAT (Memory Analyzer) • jcmd (Command Hub)[ 诊断工具的环境映射 ] │ ┌───────────────────────────────────┼───────────────────────────────────┐ ▼ ▼ ▼ 【本地/测试环境】 【线上生产环境】 【事后/离线分析】 (带 GUI / 允许高开销) (无 GUI / 低损耗 / 严禁停机) (大 Dump / 离线分析) • VisualVM • CLI 工具 (jstat/jcmd) • MAT • JConsole • Arthas (热插拔诊断) • JMC (配合 JFR 文件) • IDE Profiler • JFR (开启 low-overhead)速记口诀jps查进程jstat看 GCjmap吐堆体jstack抓死锁jcmd一招鲜MAT剖泄漏线上疑难杂症直接Arthas上。️ 02 CLI 命令行工具轻量、无 GUI 依赖生产环境特别是 K8s Pod 或 Linux minimal 镜像通常没有 GUI 图形界面命令行工具是排查故障的第一选择。 2.1 基础诊断“四大天王”1.jps(JVM Process Status Tool)语义Java 版的 Linuxps命令。作用列出目标机器上正在运行的 Java 进程 IDPID及主类名。常用指令# 显示进程 ID、主类完整包名以及传递给 main 方法的参数jps-l-v2.jstat(JVM Statistics Monitoring Tool)语义Java 统计信息监控Statistics。作用实时查看 GC 状态、堆内存各区域使用率、类加载情况。开销极小适合生产环境连续监测。常用指令# 每 1000ms 打印一次 PID18241 的 GC 内存占比百分比jstat-gcutil1824110003.jmap(Memory Map for Java)语义Java 内存映射Memory Map。作用获取堆内存详细信息、打印对象直方图以及导出堆转储快照Heap Dump。常用指令# 打印存活对象的类名、实例数、占用内存大小按占用降序jmap-histo:live18241|head-n20# 手动导出 Dump 文件注意会引发全堆扫描与短时间 STW 卡顿jmap-dump:formatb,file/tmp/heap.hprof182414.jstack(Stack Trace for Java)语义Java 线程堆栈跟踪Stack Trace。作用导出 JVM 当前时刻的线程快照。常用于定位 CPU 100%、死锁Deadlock、线程冻结/无限等待问题。常用指令# 导出进程的完整线程堆栈jstack-l18241/tmp/thread_stack.log 2.2 万能集成命令 (jcmd)jcmd(JVM Command) 是 JDK 7 引入的多功能万能命令。官方推荐替代jmap和jstack其性能开销更小且功能更丰富。常用指令# 1. 列出目标 PID 支持的所有子命令jcmd18241Help# 2. 替代 jstack打印线程堆栈jcmd18241Thread.print# 3. 替代 jmap导出堆转储文件jcmd18241GC.heap_dump /tmp/jcmd_heap.hprof# 4. 打印 JVM 启动参数jcmd18241VM.flags 03 图形化/监控诊断工具GUI 与离线分析 3.1 经典可视化面板1.JConsole(Java Monitoring and Management Console)定位基于JMX (Java Management Extensions)的经典内置监控控制台。用处连接远程/本地进程查看堆内存趋势、线程数、类加载数以及 CPU 利用率。UI 较老适合开发测试阶段快速观察。2.VisualVM(All-in-One GUI)定位全能型桌面诊断工具。用处集成jstat、jstack、jmap功能支持 CPU/内存 Profiling、线程状态分析可直接打开.hprof堆快照进行初级分析。 3.2 飞行记录仪与低消耗诊断JMC(Java Mission Control) JFR(Java Flight Recorder)定位生产级低损耗持续监控分析套件OpenJDK 11 已完全开源。用处JFR飞行记录仪内置在 JVM 内部的采样收集器生产环境额外开销 1 % 1\%1%。持续记录 CPU 消耗、锁竞争、内存分配、GC 停顿、I/O 阻塞等事件。JMC客户端用于解析 JFR 生成的.jfr日志文件提供精细的时间轴回放分析。场景专门解决复现难度高、偶发性卡顿、对性能损耗敏感的线上疑难杂症。 3.3 堆转储分析神器MAT(Eclipse Memory Analyzer Tool)定位大内存堆转储文件.hprof分析工具。用处系统发生OutOfMemoryError时导入数 G 到数十 G 的 Dump 文件Leak Suspects自动计算概率最大的内存泄漏源。Dominator Tree支配树分析哪些对象占用了最多的保留内存Retained Heap。Path to GC Roots一键追踪泄漏对象被谁强引用持有导致无法被 GC 回收。 3.4 线上零侵入动态诊断Arthas(阿里开源 Java 诊断利器)定位线上故障排查的标准配置。用处以 Attach 方式挂载到目标 Java 进程无需重启服务thread -n 3秒级定位 CPU 消耗最高的线程。jad反编译线上正在运行的 Class确认运行代码版本。**watch/trace**动态插桩无需加 Log 即可观察线上方法调用的入参、返回值、抛出的异常及各子步骤耗时排查慢接口。⚙️ 04 工具选型对比与真实工业场景 4.1 全景选型对比表工具名称界面形态开销/生产可用性核心适用场景一句话总结jpsCLI极低可线上快速查找 Java PIDJava 版psjstatCLI极低可线上实时监测 GC 频次与内存占比命令行看 GC 首选jmapCLI高导出 Dump 会 STW导出.hprof或查看对象直方图内存快照导出器jstackCLI低可线上排查 CPU 100%、线程死锁线程堆栈提取器jcmdCLI低可线上整合替代jmap/jstack等JDK 多合一命令中心JConsoleGUI中等取决于 JMX 频次本地/测试环境基本指标观察内置基础 JMX 面板VisualVMGUI中等本地开发 Profiling、分析小 Heap桌面全能型诊断工具JMC JFRGUI/日志极低生产开销 1 % 1\%1%线上偶发卡顿、高精度性能剖析生产级“黑匣子”飞行记录仪MATGUI离线分析数 G 以上大 Dump 文件深度分析内存泄漏定位神器ArthasCLI/Web动态挂载用完即卸载线上热查、方法追踪、源码反编译线上实时诊断利器 4.2 真实工业场景对照表实际工程情景推荐诊断工具组合选型依据本地 IDE 写代码/压测调优VisualVM / IDE Profiler有 GUI 界面可视化直观支持动态插桩看方法耗时。K8s Pod 突发 CPU 飙升 / GC 异常**topjstatjstack**命令行轻量极速容器内无需安装额外复杂软件。线上环境看接口入参或定位慢代码Arthas (trace/watch)不影响业务运行无需重启服务即可动态抓日志。线上 OOM 崩溃后的根因追查-XX:HeapDump... MAT事故后离线剖析自动计算支配树找内存泄漏源头。超高并发线上系统的偶发性微小卡顿JFR (线上采样) JMC (本地分析)性能损耗 1 % 1\%1%像“黑匣子”一样全天候记录细节。 05 生产排查标准流程定位进程与线程使用jps/top确认进程 PID 以及占用 CPU/内存最高的线程 ID。确认 GC 状态使用jstat检查是否为频发 Full GC 导致的系统卡顿。动态热查若允许 Attach优先使用Arthas进行在线链路追踪与线程剖析。离线根因分析发生 OOM 时拉回jmap/jcmd或自动生成的.hprof快照在本地使用MAT剖析支配树寻找泄漏源。核心总结本地用 GUIVisualVM线上用命令行jstat/jstack与 Arthas事后分析靠 MAT高并发黑匣子选 JFR。 06 如何记住具体的使用场景要做到“永久不忘”并在真实生产或面试中脱口而出关键在于拒绝孤立记忆工具名建立“场景→ \rightarrow→问题→ \rightarrow→工具”的自动化条件反射。推荐通过以下三个维度将这些工具转化为肌肉记忆1. 场景化记忆法把 10 个工具压缩成 3 个角色放弃逐个背诵按部署环境与运行姿态归类命令行五兄弟K8s Pod 内原生工具无 GUI 依赖jpsJava 版ps用来看 PID。jstat看GC 频次与各区利用率最轻量。jmap把堆内存吐成文件Dump。jstack把线程堆栈打出来查 CPU 飙升/死锁。jcmd官方推荐的万能替代者合集。线上热查与黑匣子生产环境不可停机Arthas动态挂载热查慢接口trace、看参数watch、找高 CPU 线程thread -n 3。JFR JMC开销 1 % 1\%1%的生产级黑匣子记录偶发性微小卡顿。离线/桌面分析派本地图形化 GUIMAT分析 OOM 大 Dump 文件的天花板看支配树与 GC Roots。VisualVM本地/测试环境调优 Profiling 全家桶。2. 故障诊断决策树面对问题的反射弧在实际工作或面试中顺着排查逻辑链就能推导出工具[ 发现故障/告警 ] │ ┌────────────────────────┼────────────────────────┐ ▼ ▼ ▼ 【CPU 飙升 100% / 卡死】 【内存告警 / 频繁 GC】 【线上接口响应超慢】 │ │ │ 1. jps 找 PID 1. jstat -gcutil 看频次 1. Arthas 动态 Attach 2. jstack 导线程栈 2. jmap 导 .hprof Dump 2. trace / watch 定位 (或 Arthas thread -n 3) 3. 本地 MAT 分析支配树 (无法重启加 Log 时)3. 黄金速记口诀四句顺口溜jps 找进程jstat 看 GCjstack 锁死 CPUjmap 导出堆线上慢用 ArthasOOM 剖 MAT偶发卡顿开启 JFR本地调优 VisualVM。4. 主动检索自测卡片检验记忆试着在脑海中快速回答这三个高频生产场景场景一K8s 容器内没有图形界面CPU 突然 100%你的第一组合招是什么(答案jps找到 PID→ \rightarrow→jstack打印线程栈找 RUNNABLE 线程)场景二线上接口偶尔响应延迟 5 秒不能重启服务用什么工具找拖慢速度的那一行代码(答案Arthas的trace命令)场景三系统发生 OOM 生成了 10G 的.hprof文件用什么工具找内存泄漏源头(答案MAT算支配树和 Path to GC Roots) 07 真实生产排查实战案例️ 项目背景与 JVM 诊断体系在支撑云闪付 5 亿用户量、每日千万级绑卡及生态快捷支付的场景下系统面临高频状态流转与突发高并发交易的双重考验。为保障系统 99.99% 高可用针对线上突发的性能瓶颈与内存隐患总结出两套标准的 JVM 生产排查与重构实战[ 云闪付绑卡核心服务 (K8s Pod) ] │ ┌────────────────────────────┴────────────────────────────┐ ▼ ▼ 【案例 1CPU 100% 频繁 Full GC】 【案例 2慢速 OOM 内存泄漏】 工具链top ➔ jstat ➔ Arthas 工具链jstat ➔ heapdump ➔ MAT 场景高峰期绑卡风控打分接口阻塞 场景服务运行 48 小时后老年代溢出 案例 1高峰期绑卡 core 接口 CPU 100% 伴随频繁 Full GC 诊断1. 故障现象在营销大促期间云闪付一键绑卡核心接口 RT 从 200ms 飙升至 5000ms网关层出现大量upstream timed outPrometheus 告警显示核心绑卡 Pod 节点的 CPU 利用率陡增至 100%。2. 排查过程topjstatArthasStep 1定位高 CPU 进程与 CPU 结构在 K8s Pod 终端通过top找到 CPU 消耗最高的 Java 进程PID28104。Step 2使用jstat确认 GC 运行状态执行jstat -gcutil 28104 1000 5观察 JVM 各区内存利用率及 GC 频次S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 100.00 98.50 99.85 96.20 94.10 120 2.540 1450 320.120 322.660 0.00 100.00 100.00 99.85 96.20 94.10 120 2.540 1453 321.050 323.590分析老年代占比O高达99.85%FGC每秒飙升 3 次。CPU 100% 的根本原因在于 JVM 线程陷入死循环垃圾回收STW 卡顿严重拖垮系统。Step 3无侵入挂载Arthas锁死代码位置通过 Arthas 动态 Attach 到目标进程无需重启服务执行thread -n 3抓取占用 CPU 最高的线程发现前两个为 GC Task 线程第三个为绑卡业务线程http-nio-8080-exec-12 cpuUsage32% com.unionpay.bind.service.RiskService.checkUserRisk()使用 Arthastrace动态追踪方法调用链路trace com.unionpay.bind.service.RiskService checkUserRisk -n 1发现瓶颈在同步调用第三方风控与银行鉴权打分逻辑时底层 SQL 未加分页限制一次性将 30 万条历史交易与黑名单规则加载到了堆内存中。3. 根因与优化重构根因大促高并发下海量大对象瞬间挤爆老年代触发频繁 Full GC导致 GC 线程打满 CPU。架构重构异步解耦接入RocketMQ将非核心的日志审计与风控打分打入 MQ 进行异步解耦绑卡主链路 RT 降低 30%。数据流式加载将全量查询改为 Redis 本地 Caffeine 多级缓存查询杜绝大对象直接进堆。 案例 2一键绑卡鉴权链路 ThreadLocal 慢速 OOM 内存泄漏剖析1. 故障现象云闪付微服务节点在连续运行 48 小时后老年代内存使用率呈单调递增趋势从 30% 逐步爬升至 95%最终触发 JVM 抛出java.lang.OutOfMemoryError: Java heap space导致 Pod 重启。2. 排查过程jstatheapdumpMATStep 1验证是否为“真内存泄漏”通过jcmd 31092 GC.run手动触发 Full GC同时用jstat -gcutil 31092 2000观察即便多次强行 Full GC老年代O依然维持在 89% 以上无法下降确认堆中存在被强引用死锁的废弃对象。Step 2导出 Dump 堆快照在节点重启或隔离前执行jcmd 31092 GC.heap_dump /tmp/heap_leak.hprof导出全堆快照。Step 3使用MAT(Memory Analyzer Tool) 分析 GC Roots将快照导入 MAT 工具通过Leak Suspects报告与Dominator Tree支配树分析对象保留内存Retained Heap展开支配树并右键选择Path to GC Roots - exclude weak/soft references得到强引用链Thread Local (GC Root) └── ThreadLocalMap └── ThreadLocalMap$Entry └── com.unionpay.bind.context.UserSessionContext (Retained Size 占比 78%)3. 根因与防重解决根因为了实现跨 Dubbo/Spring Cloud 调用的无感鉴权在拦截器中解析用户 Token 并装载入UserSessionContext基于ThreadLocal实现。但在 Spring MVC 拦截器的afterCompletion()钩子函数中漏写了UserSessionContext.remove()。由于 Tomcat/Dubbo 线程池中的线程被复用导致大量用户会话对象长期驻留老年代无法回收。修复与防重机制严格生命周期清理在所有 ThreadLocal 使用处强制追加try-finally结构在afterCompletion阶段执行remove()。防重机制在绑卡核心链路上增加 Redis Lua 分布式防重锁与全局幂等号校验保障并发请求下的数据精准性与链路差错率为 0。️ 生产排查与架构调优选型对照表故障类型现象与指标第一响应工具根因定位工具解决方案/架构改造高并发 CPU 打满CPU 100%、RT 5s、频繁 Full GCtopjstat -gcutilArthas(thread -n 3/trace)RocketMQ 异步解耦 分页/流式数据加载慢速内存泄漏老年代持续上升、Full GC 无法回收jcmd GC.runjstatMAT(Dominator Tree GC Roots)规范 ThreadLocal 销毁 优化 Caffeine 缓存策略并发状态冲突跨机构/银行回调乱序、数据重复落库RocketMQ 延迟重试日志Redis Lua 分布式锁全局唯一幂等号 状态机补偿机制 JVM 性能调优与故障排查全景图：从工具选型到云闪付千万级生产实战
文章目录 01 JVM 监控与诊断工具地图️ 02 CLI 命令行工具轻量、无 GUI 依赖 2.1 基础诊断“四大天王”1. jps (JVM Process Status Tool)2. jstat (JVM Statistics Monitoring Tool)3. jmap (Memory Map for Java)4. jstack (Stack Trace for Java) 2.2 万能集成命令 (jcmd) 03 图形化/监控诊断工具GUI 与离线分析 3.1 经典可视化面板1. JConsole (Java Monitoring and Management Console)2. VisualVM (All-in-One GUI) 3.2 飞行记录仪与低消耗诊断JMC (Java Mission Control) JFR (Java Flight Recorder) 3.3 堆转储分析神器MAT (Eclipse Memory Analyzer Tool) 3.4 线上零侵入动态诊断Arthas (阿里开源 Java 诊断利器)⚙️ 04 工具选型对比与真实工业场景 4.1 全景选型对比表 4.2 真实工业场景对照表 05 生产排查标准流程 06 如何记住具体的使用场景1. 场景化记忆法把 10 个工具压缩成 3 个角色2. 故障诊断决策树面对问题的反射弧3. 黄金速记口诀四句顺口溜4. 主动检索自测卡片检验记忆 07 真实生产排查实战案例️ 项目背景与 JVM 诊断体系 案例 1高峰期绑卡 core 接口 CPU 100% 伴随频繁 Full GC 诊断1. 故障现象2. 排查过程top jstat Arthas3. 根因与优化重构 案例 2一键绑卡鉴权链路 ThreadLocal 慢速 OOM 内存泄漏剖析1. 故障现象2. 排查过程jstat heapdump MAT3. 根因与防重解决️ 生产排查与架构调优选型对照表 01 JVM 监控与诊断工具地图JVM 诊断工具围绕“进程定位 - 状态监控 - 内存/线程导出 - 离线/实时分析”四步建立。工具的使用场景完全取决于运行环境的限制条件GUI 依赖、安全权限、性能损耗承受度。[ JVM 诊断工具阵营 ] │ ┌───────────────────────────────────┼───────────────────────────────────┐ ▼ ▼ ▼ 【CLI 命令行阵营】 【GUI / 离线分析】 【线上诊断神器】 轻量级、原生自带 图形化、大 Dump 离线分析 零侵入、实时热查 • jps (Process Status) • JConsole (JMX Console) • Arthas (阿里开源) • jstat (Statistics) • VisualVM (All-in-One) • jmap (Memory Map) • JMC (Mission Control) • jstack(Stack Trace) • MAT (Memory Analyzer) • jcmd (Command Hub)[ 诊断工具的环境映射 ] │ ┌───────────────────────────────────┼───────────────────────────────────┐ ▼ ▼ ▼ 【本地/测试环境】 【线上生产环境】 【事后/离线分析】 (带 GUI / 允许高开销) (无 GUI / 低损耗 / 严禁停机) (大 Dump / 离线分析) • VisualVM • CLI 工具 (jstat/jcmd) • MAT • JConsole • Arthas (热插拔诊断) • JMC (配合 JFR 文件) • IDE Profiler • JFR (开启 low-overhead)速记口诀jps查进程jstat看 GCjmap吐堆体jstack抓死锁jcmd一招鲜MAT剖泄漏线上疑难杂症直接Arthas上。️ 02 CLI 命令行工具轻量、无 GUI 依赖生产环境特别是 K8s Pod 或 Linux minimal 镜像通常没有 GUI 图形界面命令行工具是排查故障的第一选择。 2.1 基础诊断“四大天王”1.jps(JVM Process Status Tool)语义Java 版的 Linuxps命令。作用列出目标机器上正在运行的 Java 进程 IDPID及主类名。常用指令# 显示进程 ID、主类完整包名以及传递给 main 方法的参数jps-l-v2.jstat(JVM Statistics Monitoring Tool)语义Java 统计信息监控Statistics。作用实时查看 GC 状态、堆内存各区域使用率、类加载情况。开销极小适合生产环境连续监测。常用指令# 每 1000ms 打印一次 PID18241 的 GC 内存占比百分比jstat-gcutil1824110003.jmap(Memory Map for Java)语义Java 内存映射Memory Map。作用获取堆内存详细信息、打印对象直方图以及导出堆转储快照Heap Dump。常用指令# 打印存活对象的类名、实例数、占用内存大小按占用降序jmap-histo:live18241|head-n20# 手动导出 Dump 文件注意会引发全堆扫描与短时间 STW 卡顿jmap-dump:formatb,file/tmp/heap.hprof182414.jstack(Stack Trace for Java)语义Java 线程堆栈跟踪Stack Trace。作用导出 JVM 当前时刻的线程快照。常用于定位 CPU 100%、死锁Deadlock、线程冻结/无限等待问题。常用指令# 导出进程的完整线程堆栈jstack-l18241/tmp/thread_stack.log 2.2 万能集成命令 (jcmd)jcmd(JVM Command) 是 JDK 7 引入的多功能万能命令。官方推荐替代jmap和jstack其性能开销更小且功能更丰富。常用指令# 1. 列出目标 PID 支持的所有子命令jcmd18241Help# 2. 替代 jstack打印线程堆栈jcmd18241Thread.print# 3. 替代 jmap导出堆转储文件jcmd18241GC.heap_dump /tmp/jcmd_heap.hprof# 4. 打印 JVM 启动参数jcmd18241VM.flags 03 图形化/监控诊断工具GUI 与离线分析 3.1 经典可视化面板1.JConsole(Java Monitoring and Management Console)定位基于JMX (Java Management Extensions)的经典内置监控控制台。用处连接远程/本地进程查看堆内存趋势、线程数、类加载数以及 CPU 利用率。UI 较老适合开发测试阶段快速观察。2.VisualVM(All-in-One GUI)定位全能型桌面诊断工具。用处集成jstat、jstack、jmap功能支持 CPU/内存 Profiling、线程状态分析可直接打开.hprof堆快照进行初级分析。 3.2 飞行记录仪与低消耗诊断JMC(Java Mission Control) JFR(Java Flight Recorder)定位生产级低损耗持续监控分析套件OpenJDK 11 已完全开源。用处JFR飞行记录仪内置在 JVM 内部的采样收集器生产环境额外开销 1 % 1\%1%。持续记录 CPU 消耗、锁竞争、内存分配、GC 停顿、I/O 阻塞等事件。JMC客户端用于解析 JFR 生成的.jfr日志文件提供精细的时间轴回放分析。场景专门解决复现难度高、偶发性卡顿、对性能损耗敏感的线上疑难杂症。 3.3 堆转储分析神器MAT(Eclipse Memory Analyzer Tool)定位大内存堆转储文件.hprof分析工具。用处系统发生OutOfMemoryError时导入数 G 到数十 G 的 Dump 文件Leak Suspects自动计算概率最大的内存泄漏源。Dominator Tree支配树分析哪些对象占用了最多的保留内存Retained Heap。Path to GC Roots一键追踪泄漏对象被谁强引用持有导致无法被 GC 回收。 3.4 线上零侵入动态诊断Arthas(阿里开源 Java 诊断利器)定位线上故障排查的标准配置。用处以 Attach 方式挂载到目标 Java 进程无需重启服务thread -n 3秒级定位 CPU 消耗最高的线程。jad反编译线上正在运行的 Class确认运行代码版本。**watch/trace**动态插桩无需加 Log 即可观察线上方法调用的入参、返回值、抛出的异常及各子步骤耗时排查慢接口。⚙️ 04 工具选型对比与真实工业场景 4.1 全景选型对比表工具名称界面形态开销/生产可用性核心适用场景一句话总结jpsCLI极低可线上快速查找 Java PIDJava 版psjstatCLI极低可线上实时监测 GC 频次与内存占比命令行看 GC 首选jmapCLI高导出 Dump 会 STW导出.hprof或查看对象直方图内存快照导出器jstackCLI低可线上排查 CPU 100%、线程死锁线程堆栈提取器jcmdCLI低可线上整合替代jmap/jstack等JDK 多合一命令中心JConsoleGUI中等取决于 JMX 频次本地/测试环境基本指标观察内置基础 JMX 面板VisualVMGUI中等本地开发 Profiling、分析小 Heap桌面全能型诊断工具JMC JFRGUI/日志极低生产开销 1 % 1\%1%线上偶发卡顿、高精度性能剖析生产级“黑匣子”飞行记录仪MATGUI离线分析数 G 以上大 Dump 文件深度分析内存泄漏定位神器ArthasCLI/Web动态挂载用完即卸载线上热查、方法追踪、源码反编译线上实时诊断利器 4.2 真实工业场景对照表实际工程情景推荐诊断工具组合选型依据本地 IDE 写代码/压测调优VisualVM / IDE Profiler有 GUI 界面可视化直观支持动态插桩看方法耗时。K8s Pod 突发 CPU 飙升 / GC 异常**topjstatjstack**命令行轻量极速容器内无需安装额外复杂软件。线上环境看接口入参或定位慢代码Arthas (trace/watch)不影响业务运行无需重启服务即可动态抓日志。线上 OOM 崩溃后的根因追查-XX:HeapDump... MAT事故后离线剖析自动计算支配树找内存泄漏源头。超高并发线上系统的偶发性微小卡顿JFR (线上采样) JMC (本地分析)性能损耗 1 % 1\%1%像“黑匣子”一样全天候记录细节。 05 生产排查标准流程定位进程与线程使用jps/top确认进程 PID 以及占用 CPU/内存最高的线程 ID。确认 GC 状态使用jstat检查是否为频发 Full GC 导致的系统卡顿。动态热查若允许 Attach优先使用Arthas进行在线链路追踪与线程剖析。离线根因分析发生 OOM 时拉回jmap/jcmd或自动生成的.hprof快照在本地使用MAT剖析支配树寻找泄漏源。核心总结本地用 GUIVisualVM线上用命令行jstat/jstack与 Arthas事后分析靠 MAT高并发黑匣子选 JFR。 06 如何记住具体的使用场景要做到“永久不忘”并在真实生产或面试中脱口而出关键在于拒绝孤立记忆工具名建立“场景→ \rightarrow→问题→ \rightarrow→工具”的自动化条件反射。推荐通过以下三个维度将这些工具转化为肌肉记忆1. 场景化记忆法把 10 个工具压缩成 3 个角色放弃逐个背诵按部署环境与运行姿态归类命令行五兄弟K8s Pod 内原生工具无 GUI 依赖jpsJava 版ps用来看 PID。jstat看GC 频次与各区利用率最轻量。jmap把堆内存吐成文件Dump。jstack把线程堆栈打出来查 CPU 飙升/死锁。jcmd官方推荐的万能替代者合集。线上热查与黑匣子生产环境不可停机Arthas动态挂载热查慢接口trace、看参数watch、找高 CPU 线程thread -n 3。JFR JMC开销 1 % 1\%1%的生产级黑匣子记录偶发性微小卡顿。离线/桌面分析派本地图形化 GUIMAT分析 OOM 大 Dump 文件的天花板看支配树与 GC Roots。VisualVM本地/测试环境调优 Profiling 全家桶。2. 故障诊断决策树面对问题的反射弧在实际工作或面试中顺着排查逻辑链就能推导出工具[ 发现故障/告警 ] │ ┌────────────────────────┼────────────────────────┐ ▼ ▼ ▼ 【CPU 飙升 100% / 卡死】 【内存告警 / 频繁 GC】 【线上接口响应超慢】 │ │ │ 1. jps 找 PID 1. jstat -gcutil 看频次 1. Arthas 动态 Attach 2. jstack 导线程栈 2. jmap 导 .hprof Dump 2. trace / watch 定位 (或 Arthas thread -n 3) 3. 本地 MAT 分析支配树 (无法重启加 Log 时)3. 黄金速记口诀四句顺口溜jps 找进程jstat 看 GCjstack 锁死 CPUjmap 导出堆线上慢用 ArthasOOM 剖 MAT偶发卡顿开启 JFR本地调优 VisualVM。4. 主动检索自测卡片检验记忆试着在脑海中快速回答这三个高频生产场景场景一K8s 容器内没有图形界面CPU 突然 100%你的第一组合招是什么(答案jps找到 PID→ \rightarrow→jstack打印线程栈找 RUNNABLE 线程)场景二线上接口偶尔响应延迟 5 秒不能重启服务用什么工具找拖慢速度的那一行代码(答案Arthas的trace命令)场景三系统发生 OOM 生成了 10G 的.hprof文件用什么工具找内存泄漏源头(答案MAT算支配树和 Path to GC Roots) 07 真实生产排查实战案例️ 项目背景与 JVM 诊断体系在支撑云闪付 5 亿用户量、每日千万级绑卡及生态快捷支付的场景下系统面临高频状态流转与突发高并发交易的双重考验。为保障系统 99.99% 高可用针对线上突发的性能瓶颈与内存隐患总结出两套标准的 JVM 生产排查与重构实战[ 云闪付绑卡核心服务 (K8s Pod) ] │ ┌────────────────────────────┴────────────────────────────┐ ▼ ▼ 【案例 1CPU 100% 频繁 Full GC】 【案例 2慢速 OOM 内存泄漏】 工具链top ➔ jstat ➔ Arthas 工具链jstat ➔ heapdump ➔ MAT 场景高峰期绑卡风控打分接口阻塞 场景服务运行 48 小时后老年代溢出 案例 1高峰期绑卡 core 接口 CPU 100% 伴随频繁 Full GC 诊断1. 故障现象在营销大促期间云闪付一键绑卡核心接口 RT 从 200ms 飙升至 5000ms网关层出现大量upstream timed outPrometheus 告警显示核心绑卡 Pod 节点的 CPU 利用率陡增至 100%。2. 排查过程topjstatArthasStep 1定位高 CPU 进程与 CPU 结构在 K8s Pod 终端通过top找到 CPU 消耗最高的 Java 进程PID28104。Step 2使用jstat确认 GC 运行状态执行jstat -gcutil 28104 1000 5观察 JVM 各区内存利用率及 GC 频次S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 100.00 98.50 99.85 96.20 94.10 120 2.540 1450 320.120 322.660 0.00 100.00 100.00 99.85 96.20 94.10 120 2.540 1453 321.050 323.590分析老年代占比O高达99.85%FGC每秒飙升 3 次。CPU 100% 的根本原因在于 JVM 线程陷入死循环垃圾回收STW 卡顿严重拖垮系统。Step 3无侵入挂载Arthas锁死代码位置通过 Arthas 动态 Attach 到目标进程无需重启服务执行thread -n 3抓取占用 CPU 最高的线程发现前两个为 GC Task 线程第三个为绑卡业务线程http-nio-8080-exec-12 cpuUsage32% com.unionpay.bind.service.RiskService.checkUserRisk()使用 Arthastrace动态追踪方法调用链路trace com.unionpay.bind.service.RiskService checkUserRisk -n 1发现瓶颈在同步调用第三方风控与银行鉴权打分逻辑时底层 SQL 未加分页限制一次性将 30 万条历史交易与黑名单规则加载到了堆内存中。3. 根因与优化重构根因大促高并发下海量大对象瞬间挤爆老年代触发频繁 Full GC导致 GC 线程打满 CPU。架构重构异步解耦接入RocketMQ将非核心的日志审计与风控打分打入 MQ 进行异步解耦绑卡主链路 RT 降低 30%。数据流式加载将全量查询改为 Redis 本地 Caffeine 多级缓存查询杜绝大对象直接进堆。 案例 2一键绑卡鉴权链路 ThreadLocal 慢速 OOM 内存泄漏剖析1. 故障现象云闪付微服务节点在连续运行 48 小时后老年代内存使用率呈单调递增趋势从 30% 逐步爬升至 95%最终触发 JVM 抛出java.lang.OutOfMemoryError: Java heap space导致 Pod 重启。2. 排查过程jstatheapdumpMATStep 1验证是否为“真内存泄漏”通过jcmd 31092 GC.run手动触发 Full GC同时用jstat -gcutil 31092 2000观察即便多次强行 Full GC老年代O依然维持在 89% 以上无法下降确认堆中存在被强引用死锁的废弃对象。Step 2导出 Dump 堆快照在节点重启或隔离前执行jcmd 31092 GC.heap_dump /tmp/heap_leak.hprof导出全堆快照。Step 3使用MAT(Memory Analyzer Tool) 分析 GC Roots将快照导入 MAT 工具通过Leak Suspects报告与Dominator Tree支配树分析对象保留内存Retained Heap展开支配树并右键选择Path to GC Roots - exclude weak/soft references得到强引用链Thread Local (GC Root) └── ThreadLocalMap └── ThreadLocalMap$Entry └── com.unionpay.bind.context.UserSessionContext (Retained Size 占比 78%)3. 根因与防重解决根因为了实现跨 Dubbo/Spring Cloud 调用的无感鉴权在拦截器中解析用户 Token 并装载入UserSessionContext基于ThreadLocal实现。但在 Spring MVC 拦截器的afterCompletion()钩子函数中漏写了UserSessionContext.remove()。由于 Tomcat/Dubbo 线程池中的线程被复用导致大量用户会话对象长期驻留老年代无法回收。修复与防重机制严格生命周期清理在所有 ThreadLocal 使用处强制追加try-finally结构在afterCompletion阶段执行remove()。防重机制在绑卡核心链路上增加 Redis Lua 分布式防重锁与全局幂等号校验保障并发请求下的数据精准性与链路差错率为 0。️ 生产排查与架构调优选型对照表故障类型现象与指标第一响应工具根因定位工具解决方案/架构改造高并发 CPU 打满CPU 100%、RT 5s、频繁 Full GCtopjstat -gcutilArthas(thread -n 3/trace)RocketMQ 异步解耦 分页/流式数据加载慢速内存泄漏老年代持续上升、Full GC 无法回收jcmd GC.runjstatMAT(Dominator Tree GC Roots)规范 ThreadLocal 销毁 优化 Caffeine 缓存策略并发状态冲突跨机构/银行回调乱序、数据重复落库RocketMQ 延迟重试日志Redis Lua 分布式锁全局唯一幂等号 状态机补偿机制