PDF大白话说Java面试题 — 02-JVM篇第28题对于 JDK 自带的监控和性能分析工具用过哪些一般你怎么用的回答核心考点大厂面试要求熟练掌握 JDK 自带工具并能结合场景说明使用时机、命令参数、结果解读。不能只会罗列工具名称。1. 工具全景图工具核心用途是否需要目标进程是否STWjps列出 Java 进程 PID是否jinfo查看/修改 JVM 参数是否jstatGC 和内存区域实时统计是否jmap堆内存快照dump是是严重jstack线程堆栈快照是否但可能略慢jcmd多功能综合工具JDK 7是部分操作会VisualVM图形化综合监控是可本地/远程采样模式不影响2. 各工具典型用法附命令2.1jps定位目标进程jps-l# 显示完整主类名jps-v# 显示传递给 JVM 的参数场景启动分析前第一步拿到 PID。2.2jstat实时监控 GC最常用# 每1秒打印一次共打印10次jstat-gcutilPID100010# 输出列解读# S0/S1: Survivor 使用率# E: Eden 使用率# O: 老年代使用率# M: 元空间使用率# YGC/YGCT: Young GC 次数/总耗时# FGC/FGCT: Full GC 次数/总耗时# GCT: GC 总耗时实战判断YGC每分钟超过60次 → 年轻代太小FGC每小时 1 次 → 需排查除非元空间/堆合理调优后仍存GCT / 运行时长 10% → GC 已严重影响吞吐2.3jmap堆内存快照谨慎使用# 生成 dump 文件会触发 Full GC生产需低峰期jmap -dump:live,formatb,file/tmp/heap.hprofPID# 查看对象统计不会 dump 大文件但仍会 STWjmap-histo:livePID|head-30⚠️ 重要-dump:live会先触发 Full GCSTW 时间可能达数秒甚至分钟生产环境优先用-XX:HeapDumpOnOutOfMemoryError自动 dump高并发系统用jcmd PID GC.heap_dump /path/dump.hprof底层同 jmap依然 STW分析 dump用MATEclipse Memory Analyzer或VisualVM查看 Leak Suspects、Dominator Tree。2.4jstack线程快照无痛# 导出线程栈jstack-lPIDthread.dump# 快速统计线程状态grepjava.lang.Thread.Statethread.dump|sort|uniq-c经典用法CPU 飙高top -H -p PID找线程 ID十进制的 →printf %x\n 十进制tid→ 在 jstack 输出中搜索十六进制 tid死锁jstack 输出末尾会直接报告“Found one Java-level deadlock”接口超时连续多次打印 jstack对比 WAITING/BLOCKED 线程是否一直卡在同一位置2.5jinfo查看运行时参数# 查看所有可设置参数及当前值jinfo-flagsPID# 查看单个参数jinfo-flagUseG1GCPID# 动态修改部分参数支持jinfo-flagHeapDumpOnOutOfMemoryErrorPID场景线上验证-Xmx是否生效、某个 GC 参数是否真的被打开。2.6jcmd新一代瑞士军刀JDK 7 推荐# 列出所有可执行命令jcmdPIDhelp# 查看 JVM 运行时参数替代 jinfo -flagsjcmdPIDVM.flags# 手动触发 GC慎用仅测试jcmdPIDGC.run# 获取系统属性jcmdPIDVM.system_properties# 获取线程栈同 jstackjcmdPIDThread.print# 生成 heap dumpjcmdPIDGC.heap_dump /tmp/dump.hprof# 查看 Native 内存诊断直接内存/堆外jcmdPIDVM.native_memory summary优势统一入口输出结构更清晰部分操作比 jmap 更安全。2.7VisualVM图形化利器连接方式本地自动检测本机 Java 进程远程通过 JMX需开启-Dcom.sun.management.jmxremote常用 TabMonitorCPU/堆/元空间/类/线程 实时曲线Threads线程状态及堆栈可检测死锁SamplerCPU 采样 → 热点方法内存采样 → 对象分配统计Profiler需插件更精确但开销大生产慎用生产远程连接示例JMX 参数-Dcom.sun.management.jmxremotetrue\-Dcom.sun.management.jmxremote.port9999\-Dcom.sun.management.jmxremote.authenticatefalse\-Dcom.sun.management.jmxremote.sslfalse3. 实战案例生产 Full GC 频繁排查现象服务 GC 报警FGC每小时 12 次老年代占用率 95% 不降。步骤步骤工具命令发现1jpsjps -lPID 123452jstatjstat -gcutil 12345 1000O老年代始终 98%FGC 持续增长3jmap低峰期jmap -histo:live 12345 | head -20byte[]占 80%自定义SessionCache对象异常多4jstackjstack 12345 t.dump大量线程在SessionCache.put等待锁5定位代码结合业务日志缓存未设过期时间且未限制最大容量6修复代码改用Caffeine缓存 TTL上线后 FGC 降为 04. 面试官追问示例Q1jmap -histo:live会触发 Full GC 吗A会。live参数会先执行一次 Full GC 再统计存活对象。生产环境慎用优先用jstat看趋势或 Arthasheapdump。Q2jstack打印出的BLOCKED线程很多一定有问题吗A不一定。若BLOCKED是瞬时锁竞争且正常情况如synchronized高并发只要不持续堆积就正常。需多次打印确认是否一直卡在同一锁。Q3远程连接 VisualVM 不安全怎么办A生产禁止明文 JMX。替代方案用jstat/jstack本地执行后导出分析用 Arthas阿里开源隧道连接开启 JMX SSL 认证复杂Q4jcmd能完全替代jmap吗A大部分可以。jcmd GC.heap_dump同jmap -dump但jcmd VM.native_memory是 jmap 没有的功能。不过jmap -histo的快速对象统计jcmd 没有直接等价命令。Q5生产环境不能安装任何额外工具只有 JDK 自带怎么排查A就用jps/jstat/jstack/jmap/jcmd组合。例如CPU 高 →top -H -p PIDjstack内存泄漏 →jstat -gcutil看 O 区持续增长 jmap -dump:live择低峰期GC 频繁 →jstat -gc看明细面试官想要的满分总结“日常问题排查我按以下组合使用jps找 PIDjstat -gcutil看 GC 趋势决定是否需要 dumpjstack查线程阻塞/死锁/热点栈jmap只在低峰期或 OOM 后分析 dumpjcmd作为统一入口尤其 VM.native_memory 排查堆外内存VisualVM用于本地或开发环境做性能分析核心原则生产环境首选无侵入工具jstat/jstack/jcmd 非 live 操作jmap 务必审批后执行。”觉得对您有帮助麻烦点点关注啦您的关注是我创作的最大动力~
