1. 为什么JRE命令行工具是运维工程师的瑞士军刀作为在Java服务运维一线摸爬滚打多年的老鸟我见过太多同事面对生产环境问题时的茫然无措。当服务突然CPU飙高、内存泄漏或是线程阻塞时图形化工具往往鞭长莫及。这时JRE自带的命令行工具就成了我们最后的救命稻草。这些看似简陋的命令行工具实际上封装了JVM最底层的诊断能力。比如上周我们有个核心支付服务出现Full GC频繁的问题就是通过jstat快速定位到老年代内存回收异常再用jstack抓取线程堆栈发现是第三方SDK的缓存设计缺陷。整个过程从发现到定位只用了3分钟——这就是命令行工具的效率。2. 核心工具链深度解析2.1 基础状态三件套java -version这个看似简单的命令实际上隐藏着关键信息$ java -version java version 1.8.0_281 Java(TM) SE Runtime Environment (build 1.8.0_281-b09) Java HotSpot(TM) 64-Bit Server VM (build 25.281-b09, mixed mode)第一行显示的是JRE规范版本第二行包含具体的build编号注意安全补丁版本第三行区分了JVM类型Server/Client和运行模式jps命令我习惯加上-l参数显示完整主类名$ jps -l 12345 com.example.OrderService 67890 sun.tools.jps.Jps常见问题看不到预期进程可能是权限问题试试sudo输出为空检查JAVA_HOME是否指向了正确的JREjinfo可以动态查看和修改JVM参数$ jinfo -flags 12345 Attaching to process ID 12345, please wait... Debugger attached successfully. Non-default VM flags: -XX:CICompilerCount4 -Xms512m -Xmx2g2.2 性能监控双雄jstat是我使用频率最高的工具典型场景$ jstat -gcutil 12345 1000 5 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 96.88 70.31 45.67 95.22 91.45 152 3.245 5 1.876 5.121关键列解读O老年代使用率超过80%就要警惕FGCFull GC次数突然增长可能预示内存泄漏GCTGC总时间占比超过10%就需要优化jmap的内存快照功能在OOM现场保留中不可或缺$ jmap -dump:live,formatb,fileheap.hprof 12345 Dumping heap to /tmp/heap.hprof... Heap dump file created注意生产环境慎用live参数会触发Full GC大堆内存8G建议先通过jstat确认必要性2.3 线程分析利器jstack的威力在于能瞬间捕获线程快照$ jstack -l 12345 thread_dump.log我通常这样分析grep BLOCKED thread_dump.log 找阻塞线程统计同一堆栈的出现频率结合jstat的CPU使用情况交叉验证典型死锁特征Thread-1 #12 prio5 os_prio0 tid0x00007f48740d8000 nid0x5e03 waiting for monitor entry [0x00007f486b7f6000] java.lang.Thread.State: BLOCKED (on object monitor at com.example.DeadLock.methodB(DeadLock.java:20))3. 实战问题排查流程3.1 CPU飙高问题七步定位法上周处理的一个真实案例top -Hp 12345 发现PID 4567占用300% CPUprintf %x\n 4567 得到11d7jstack 12345 | grep -A 20 11d7 定位到堆栈发现是正则表达式Catastrophic Backtracking临时用kill -3 12345保存现场通知开发修复正则模式用jstat持续监控GC情况3.2 内存泄漏排查三板斧某次电商大促前的压测经历jstat -gcutil 发现O区持续增长不回收jmap -histo:live 发现某缓存类实例异常多jmap -dump获取完整堆转储用MAT分析发现是静态Map未清理临时方案增加-XX:SoftRefLRUPolicyMSPerMB参数最终方案改用WeakHashMap重构缓存4. 高阶技巧与避坑指南4.1 安全防护要点生产环境限制工具访问# 在java.security配置 jdk.jvmstat.permitRestrictedtrue敏感信息过滤jstack 12345 | grep -v password4.2 自动化监控方案我常用的监控脚本模板#!/bin/bash PID$(jps -l | grep MyApp | awk {print $1}) [ -z $PID ] exit 1 # 每隔5秒采集一次 jstat -gcutil $PID 5000 | awk { print strftime(%Y-%m-%d %H:%M:%S), $0; if ($4 80) system(jstack -l PID /tmp/thread_dump_ strftime(%s) .log); if ($8 5) send_alert(FullGC频繁); } PID$PID4.3 常见误区警示不要在生产环境频繁执行jmap -histo:livejstack结果中的nid是LWP ID而非系统PID容器环境中注意PID namespace隔离问题JDK 9需要使用jhsdb替代部分命令5. 工具链扩展建议对于复杂问题我会组合使用arthas进行动态诊断async-profiler做火焰图分析greys进行方法级监控比如最近排查的一个RPC超时问题# 用arthas监控方法耗时 watch com.example.Service methodName {params,returnObj} -x 3 -n 5 # 用async-profiler生成火焰图 ./profiler.sh -d 30 -f /tmp/flamegraph.html 12345这些年来最大的体会是命令行工具就像老中医的把脉看似简单却需要多年经验才能准确判断。建议新手从每天收集一次jstat数据开始慢慢培养对JVM状态的直觉。