先讲一个大家可能都经历过的场景线上业务突然告警CPU飙到百分之九十多接口响应从几十毫秒涨到几秒业务方在群里疯狂而你面前只有一个黑乎乎的终端。这时候如果对JVM监控与诊断这套技术没有底别说定位问题了连该从哪个命令下手都发懵。JVM监控和诊断说白了就是解决这类问题的核心能力——既要能管住进程层面的存活、资源占用又要在性能劣化时快速定位到代码、线程、内存、GC这些具体环节。这篇文章我会围绕JVM的进程管理、堆栈分析、GC分析、参数调优和指标监控展开都是一线排查时真正用得到的方法和命令适合刚接触JVM的小白也适合正在维护生产系统的后端工程师哪怕你只是准备JVM面试这里面的细节也能直接用上。我现在仍然记得第一次处理线上JVM问题时的窘迫用jps找不到进程用jstack打印出来的线程栈完全看不懂最后只能盲猜重启。后来随着踩坑越来越多才逐渐意识到JVM监控与诊断不是某个单一工具就能搞定的它是一套方法论需要从进程管理开始一层一层深入到线程、堆内存、GC、以及运行期参数。这篇文章就把这套方法论完整梳理一遍把我这些年实际用过的方案、命令、以及踩过的坑全部写出来。1. 整体设计与监控体系搭建思路1.1 先理清监控对象JDK、JRE、JVM到底在监控什么很多初学者被 JDK、JRE、JVM 这三个词搞得头晕实际搞监控和诊断前这两段关系必须清楚JDK 是 Java 开发工具包里面包含了 JRE、编译器 javac、调试工具 jdb 以及各种命令行工具JRE 是 Java 运行环境包含 JVM 和核心类库而 JVM 本身只是一个执行字节码的虚拟机进程。全链路的问题排查里开发者关注 JDK 的编译和调试部署者关注 JRE 的运行环境而监控和诊断的对象则是 JVM——它才是真正吃掉 CPU、内存跑你代码的那个进程。从监控视角看JVM 进程实际可以拆成三层来观察。第一层是系统进程层看的是一个 java 进程在操作系统层面的 CPU、内存、文件句柄、线程数第二层是 JVM 内部层看的是堆内存、非堆内存、GC 频率、线程状态第三层是应用层看的是接口耗时、连接池使用率、慢 SQL 这类业务指标。我在设计监控方案时一定会把这三层分开因为它们的工具、命令、告警阈值完全不同。1.2 核心监控指标与观察方法把 JVM 想象成一个大型食堂堆内存就是备菜区GC 就像保洁员一边清理用完的餐盘垃圾对象一边还想办法让新菜新对象有地方放。食堂能不能高效运转取决于备菜区够不够大、保洁员清理动作快不快、会不会频繁大规模清场Full GC。对应到 JVM 监控上最核心的指标有这么几个堆内存使用率、Young GC 频率与耗时、Full GC 频率与耗时、线程数量与 BLOCKED 线程数、JIT 编译线程负载、以及进程本身的 CPU 和内存占用。我的经验是不要一上来就追求十几个指标先抓四个最关键的指标常用命令/工具重点关注进程存活与资源jps、top、ps进程是否在、CPU/内存是否异常堆内存使用jstat、VisualVM老年代是否持续增长、是否接近 OOMGC 频率与停顿jstat -gcutil、GC日志YGC 是否过频、FGC 是否发生、暂停时间线程状态jstack、jconsoleBLOCKED/WAITING 比例、死锁上面这套指标覆盖了从“进程活着吗”到“进程为什么慢”的完整链路足够应对绝大多数线上问题。1.3 监控工具链选型JVM 监控工具这几年变化不算大但选型还是有规律可循。JDK 自带的命令行工具jps、jstack、jmap、jstat、jinfo、jcmd是底线不管什么环境、有没有图形界面都得用它们图形化工具里 VisualVM 和 JMCJava Mission Control适合开发联调和线下分析但生产环境一般没有条件开图形界面如果要做长期指标趋势和告警就得引入 Prometheus 体系用 JMX Exporter 把 JVM 指标暴露出来再由 Prometheus 抓取最终落到 Grafana 看板。我之前搭过一个对接到个人系统的 Prometheus 监控环境思路其实不复杂给目标 Java 进程挂上jmx_prometheus_javaagent它会在指定端口暴露/metrics接口Prometheus 里配置一个scrape_jobs定期抓取Grafana 负责展示。这套方案的优点是指标覆盖面全、存储时间久、告警规则可以自定义而且 jvm 相关的指标名比如jvm_memory_used_bytes、jvm_gc_pause_seconds都是社区统一标准查资料非常方便。2. 进程管理与核心命令实操2.1 用 jps 和系统命令快速定位进程绝大多数排查场景第一步都是找到目标 Java 进程。此时jps是我最常用的命令它能列出当前用户下所有 Java 进程的 PID配合-l显示完整主类名、-v显示启动参数基本能把进程身份搞清楚。比如jps -l -v | grep order-service可以快速定位到某个微服务的进程号和完整的 JVM 启动参数。但这里有个隐蔽的坑如果你用的是 Docker 容器部署的 Java 程序直接在宿主机上执行jps可能看到的是宿主机上的其他 Java 进程甚至因为权限隔离根本看不到容器内的进程。遇到这种情况正确做法是docker exec -it 容器名 jps -l进入容器里执行或者上到容器内直接ps -ef找对应的 java 进程。容器场景还有一个老生常谈的记忆点不要在生产环境直接用jmap -dump导大堆容易把容器内存直接打爆。2.2 线程诊断jstack 的正确打开方式定位线程级问题jstack是绕不开的。它能打印出指定进程当前所有线程的快照包括线程名、状态、栈帧、锁信息。我通常会在三个场景下使用一是 CPU 飙高时定位是哪个线程在疯狂计算二是接口卡死时看线程卡在哪个调用上三是怀疑死锁时检查是否有循环等待锁。实际使用中jstack的输出非常长几百个线程是常态绝对不能整个人肉去翻一定要配合 grep 和上下文过滤。举个例子我在排查 CPU 飙升时会先top -Hp pid拿到 JVM 进程中 CPU 占用最高的那个线程的 PID然后转成十六进制printf %x\n 线程PID再执行jstack pid | grep -A 20 nid0x十六进制就能直接看到那个线程此刻执行的代码栈通常问题代码一眼就能看清。这个组合拳直到今天都是我处理 CPU 问题的首选。2.3 堆内存分析与堆转储当怀疑内存泄漏或堆配置不合理时jmap是第一选择。jmap -heap pid可以查看堆的配置信息初始大小、最大值、各代空间以及当前使用率jmap -histo pid可以看所有类实例数量和占用内存排行快速定位是否有某个类的对象数量异常膨胀jmap -dump:formatb,file/path/heap.hprof pid则能导出一份完整的堆转储文件交给 MAT、JProfiler 这类工具做深度的引用链分析。实操上我强烈建议生产环境提前开启 OOM 自动转储在 JVM 启动参数里加上-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/heapdump.hprof这样一旦发生 OutOfMemoryErrorJVM 会自动把当时的堆现场保存下来不需要人工现场执行jmap也避免因手动 dump 导致的二次故障。很多人在进程异常重启后手忙脚乱地找日志其实除了 stdout 和业务日志你还需要看hs_err_pid*.log崩溃日志、GC 日志、以及自动 dump 的 hprof 文件。JVM 日志在哪儿这个问题说到底是启动参数怎么配的问题配好了就自动化。2.4 运行期参数查看与含义分析jinfo是查看和部分修改运行期 JVM 参数的利器。jinfo -flags pid能列出进程当前生效的所有非默认参数jinfo -flag 参数名 pid能单独查某个参数的值。很多面试题喜欢问-XX:CompileThreshold这个参数表示一个方法被调用多少次之后触发 JIT 编译默认是 10000。它直接影响启动阶段到稳定运行之间的过渡短生命周期应用比如命令行工具、Spark 任务可以把阈值调低到 1000 甚至 500让热点方法更早被编译成本地代码缩短预热时间但长跑的服务不要乱调低否则 JIT 编译线程会频繁抢 CPU反而拖慢整体吞吐。有一次我排查一个启动特别慢的服务通过jinfo看到编译相关的参数都是默认值结合线上是低并发内部系统短请求、长时间空闲我把 CompileThreshold 调低后配合预热脚本启动到稳定时间从四五分钟缩短到两分钟以内。这种调优的思路就是基于对参数语义的理解而不是盲目抄网上的“最优配置”。3. 性能分析实战从指标采集到故障排查3.1 建立性能基线核心指标收集想要区分“服务正常”和“服务异常”前提是知道正常时各项指标长什么样所以我做任何调优前都会先采集一组性能基线。最简单直接的方式是用jstatjstat -gcutil pid 1000这个命令每秒钟输出一次年轻代、老年代、元空间的使用百分比以及 YGC、FGC 次数和各自的累计耗时。连续观察几分钟后基本能掌握服务在无压力状态下的 GC 节奏后续压测或线上出问题时对比基线就能快速发现异常。另外生产环境必须把 GC 日志打开不然排查 Full GC 问题时两眼一抹黑。JDK 8 及以前用-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/data/logs/gc.logJDK 11 及以后则统一用新的-Xlog语法-Xlog:gc*:file/data/logs/gc.log:time,uptime,levelGC 日志里能看到每次 GC 前后的堆占用、停顿耗时、回收效果是分析 G1 收集器行为的重要一手资料。要理解 G1先记住它的核心设计把堆分成若干大小相同的 Region收集时优先回收垃圾最多的 Region通过这种方式控制停顿时间。G1 分区模型和之前的串行、CMS 都不一样调优时盯着-XX:MaxGCPauseMillis和-XX:G1HeapRegionSize就行不要一上来就乱改NewRatio、SurvivorRatio这类在老收集器下的参数。3.2 CPU 飙升排查实操案例一次真实案例线上订单服务 CPU 突增到 160%接口大面积超时。我是这样一步步查的先用top定位到 java 进程确认不是其他进程在捣乱。随后top -Hp java进程PID找到 CPU 占用最高的几个线程记录线程 PID 为 58326。然后用printf %x\n 58326得到十六进制e3d6接着执行jstack pid /tmp/thread.log grep -A 20 nid0xe3d6 /tmp/thread.log输出显示线程卡在一个正则表达式匹配方法上。顺着栈帧往下看是请求参数里的某个变态字符串进入了Pattern.matcher且匹配路径极长。后续修复方式是引入正则超时机制并用更安全的自定义解析替代部分场景。这种排查套路我已经用过很多次核心链路就是系统命令找进程 - 线程维度找热点 - 栈帧定位代码 - 结合上下文修复。不要跳过第一步直接jstack否则上百个线程里不知道哪个才是问题线程。3.3 内存泄漏与 GC 异常诊断内存问题的典型特征是启动初期正常运行几小时后接口越来越慢jstat显示老年代使用率持续上涨Full GC 之后老年代使用率也没有明显下降。这基本就是对象被不该持有的引用链持有导致垃圾回收器无法回收。遇到这种情况我一般分三步走。第一步确认不是堆配置过小先看jstat -gcutil的 FGC 次数和 FGC 后老年代使用率第二步jmap -dump导出堆转储利用 MAT 的 Dominator Tree 查看占用最大的对象及引用链第三步沿着引用链定位代码修复后验证。常见的泄漏源头有缓存 Map 无上限写入、ThreadLocal 使用后未调用 remove、静态集合存储请求数据、未关闭的 IO/NIO 资源等。有一次我排查的问题根因是第三方 SDK 内部用一个静态列表记录所有回调对象日积月累撑爆了整个堆这类问题光调堆大小是没用的只能定位到具体引用链并把对象释放掉。3.4 把监控接进来Prometheus Grafana当手头的服务不再是一两台而是几十上百个实例时靠命令一个个连上去查是不现实的这时候就必须把 JVM 指标接入统一的监控系统。我常用的方案就是 Prometheus 采集 JVM 指标再对接到人或团队的监控看板。启动参数基本这样加java -javaagent:/opt/jmx_prometheus_javaagent-0.20.0.jar12345:/opt/jvm_exporter_config.yaml \ -jar app.jarjvm_exporter_config.yaml里按需配置要暴露的规则默认配置其实已经能覆盖内存、GC、线程等核心指标。然后在prometheus.yml里加一个抓取任务scrape_configs: - job_name: jvm_app static_configs: - targets: [127.0.0.1:12345]配置完重新加载 Prometheus等待数据进来后Grafana 导入社区常见的 JVM 看板比如面板 ID 4701就能看到堆内存趋势、GC 次数、线程数等一整套图表。这里我想额外提醒一句监控不只是“看板”必须把告警规则配上推到个人系统或群里。比如 Full GC 频率超过每分钟一次、老年代使用率持续超过 85%、堆内存使用率超过 90% 持续五分钟这些都是值得提前告警的信号。4. 常见问题与排查技巧实录4.1 高频问题速查表下面这张表是我总结的 JVM 问题快速定位表使用频率非常高每次排查时对照着走基本不会跑偏症状可能原因第一步排查命令后续方向CPU 飙高死循环、正则回溯、GC线程密集top -Hp jstack定位热点线程代码接口越来越慢老年代增长、频繁 FGCjstat -gcutil堆转储分析引用链进程突然消失OOM、容器内存被杀查 hs_err、GC日志开启 HeapDump 保留现场YGC 过于频繁年轻代过小或对象分配量过大jstat -gcutil调整 -Xmn 或检查大批量对象启动极其缓慢JIT 预热慢、配置加载慢jinfo -flags调整 CompileThreshold、预热脚本死锁或线程全部 BLOCKED锁竞争、连接池耗尽jstack看锁持有线程栈这张表不能解决所有问题但每次都能把方向收敛到正确范围内。4.2 五件容易忽略的细节第一件不要在生产环境频繁做堆转储尤其是堆内存已经非常大的服务。一次 dump 会把进程卡死十几秒甚至更久流量高的时候等于主动制造故障。我更建议提前开启HeapDumpOnOutOfMemoryError让 JVM 在 OOM 时自己保存现场。确实需要手动 dump 时选择流量低峰期并且 dump 完成后立刻检查服务是否恢复。第二件堆内存参数不是越大越好。-Xmx设置过大虽然减少了 GC 频率但单次 GC 的停顿时间会拉长尤其在 G1 或 CMS 下可能出现 GC 停顿超过一秒的情况。具体设置要根据服务的对象分配速率和响应时间要求来定通常先设一个合理值再结合 GC 日志逐步微调。第三件配置了容器内存限制时不要用固定的-Xmx改用相对百分比。在 Docker 或 K8s 环境里-XX:MaxRAMPercentage75这样的参数比写死-Xmx4g更安全。原因是容器内存超限被内核直接杀掉时JVM 根本来不及做任何保护动作。第四件GC 日志和异常日志要固化到固定目录并配合日志轮转。很多人问“JVM 日志在哪儿”多半是启动参数里压根没配置日志路径。我的习惯是统一放在/data/logs/下GC 日志、崩溃日志、堆转储文件各占一个子目录并且配置好 size 和保留份数既方便监控系统采集又能避免磁盘被日志写满。第五件排查性能问题时不要只盯着 JVM 内部。有一次我花了一个晚上分析 GC 和线程栈最后发现瓶颈在数据库连接池耗尽应用线程全部卡在等待连接上JVM 本身毫发无伤。JVM 监控与诊断是重要手段但全局视角更重要。4.3 一次生产问题的完整复盘最后分享一次印象深刻的实战复盘这次问题正好把前面的知识点全串了起来。某个内部管理系统的服务每两周出现一次接口严重变慢重启后恢复过一段时间又复发。第一次遇到时团队直接重启了事没有保留现场。第二次我提前在启动参数里开了 GC 日志、OOM 自动转储、并把内存指标接到了 Prometheus。问题再次出现时我看监控看板发现堆内存老年代从 40% 一路涨到 90%Full GC 每十分钟一次但 FGC 之后老年代只从 90% 微降到 85%这说明对象根本没有被回收掉基本确定是内存泄漏。通过jmap -dump导出堆转储用 MAT 一看 Dominator Tree发现罪魁祸首是一个自定义注解处理工具类里的静态 Map——每次请求都会往里面写入一条业务数据做缓存但永远没有清理。这个缓存对象累计到一定量把老年代占满Full GC 也回收不了。修复方式很简单改用弱引用或定期清理的缓存结构。修复上线后持续观察了两周老年代稳定在 20% 左右FGC 几乎消失。事后我在团队定了一个规矩所有 Java 服务启动参数必须带上 GC 日志、OOM 转储、Prometheus 接入这三件套缺一不可。做 JVM 监控与诊断这几年我最大的感受是线上问题不可怕可怕的是问题出现了却没有数据留痕。那些能在几分钟内定位问题的老手不是比你会背命令而是他们提前把日志、指标、转储这些“现场证据”都准备好了。最后分享一个小习惯每次新服务上线前我都会先跑一轮压力测试用 jstat 记录 GC 基线用 jstack 看看高并发下的线程分布把服务“正常时的样子”牢牢刻在脑子里这样出了问题才能一眼看穿。JVM 这条路上没有银弹熟练运用好进程管理、堆栈分析、GC 分析和指标监控这套组合拳已经能解决绝大多数难题。