1. 为什么JRE命令行工具是运维工程师的瑞士军刀
在服务器运维的日常工作中，我们常常会遇到各种Java应用的性能问题、内存泄漏或是线程阻塞。当应用运行在无GUI环境的服务器上时，那些依赖图形界面的监控工具往往束手无策。这时，JRE自带的命令行工具就成为了我们最可靠的"急救包"。
我曾在一次生产环境事故中，通过jstack快速定位到一个死锁问题，避免了整个系统的雪崩。那次经历让我深刻认识到，熟练掌握这些工具就像医生掌握听诊器一样重要。不同于第三方监控工具需要额外安装配置，这些命令行工具随JDK/JRE自带，开箱即用，在紧急情况下能快速响应。
2. 核心工具解析与使用场景
2.1 jps - Java进程的"身份证扫描仪"
这个看似简单的命令，实际上是我们排查问题的第一道入口。不同于系统自带的ps命令，jps能准确识别Java进程，并显示主类名或JAR文件名。
bash复制jps -lv
加上-v参数后，我们还能看到完整的JVM参数，这在排查内存设置问题时特别有用。记得有一次，一个同事忘记设置Xmx参数，导致应用频繁Full GC，就是通过这个命令快速发现的。
注意：在容器化环境中，jps可能无法看到其他容器内的Java进程，这时需要进入对应容器执行。
2.2 jstack - 线程问题的"X光机"
当应用出现卡顿、请求超时，jstack就是我们的首选工具。它能生成线程的快照，揭示死锁、线程阻塞等问题的真相。
bash复制jstack -l <pid> > thread_dump.log
我通常会连续执行3-5次jstack，间隔2-3秒，这样可以捕捉到线程状态的演变过程。曾经有个案例，通过对比多个dump文件，发现了一个周期性出现的线程竞争问题。
2.3 jmap - 内存分析的"CT扫描仪"
内存泄漏是Java应用的常见病，jmap能帮我们生成堆转储文件，用MAT或VisualVM进一步分析。
bash复制jmap -dump:live,format=b,file=heap.hprof <pid>
但要注意，在生产环境执行dump操作可能导致应用暂停，建议在低峰期操作。对于大堆应用，可以先用jmap -histo查看对象分布概况。
2.4 jstat - JVM的"心电图监测"
这个工具能实时监控GC、类加载、JIT编译等指标，特别适合观察GC行为。
bash复制jstat -gcutil <pid> 1000 10
上面的命令会每隔1秒输出一次GC统计，共10次。通过观察FGC(Full GC次数)的增长速度，可以判断是否存在内存问题。
3. 实战排查流程与技巧
3.1 CPU飙高问题的排查步骤
- 先用top找到高CPU的Java进程PID
top -Hp <pid>查看该进程中的高CPU线程- 将线程ID转为16进制：
printf "%x\n" <tid> jstack <pid> | grep -A 30 <nid>查看线程堆栈
我曾用这个方法发现过一个正则表达式导致的CPU爆满问题，线程堆栈显示卡在了Pattern.matcher方法上。
3.2 内存泄漏的排查路径
- 用jstat观察GC情况，特别是老年代使用率
- 如果老年代持续增长，执行
jmap -histo:live <pid> | head -20 - 查看排名靠前的对象是否合理
- 必要时生成堆转储进行深度分析
3.3 死锁问题的快速定位
jstack的输出中如果有"Found one Java-level deadlock"，会直接显示死锁的线程和锁信息。但更隐蔽的是资源竞争导致的逻辑死锁，这时需要分析多个线程的等待链。
4. 高级技巧与注意事项
4.1 自动化收集脚本
我通常会准备一个诊断脚本，在问题发生时一键收集所有信息：
bash复制#!/bin/bash
PID=$1
NOW=$(date +"%Y%m%d_%H%M%S")
DIR="diagnose_${NOW}"
mkdir $DIR
jps -lv > $DIR/jps_$NOW.log
jstack -l $PID > $DIR/thread_dump_$NOW.log
jmap -histo $PID > $DIR/histo_$NOW.log
jstat -gcutil $PID 1000 5 > $DIR/gc_$NOW.log
4.2 容器环境下的特殊考量
在Docker/K8s环境中，需要注意：
- 容器可能没有完整的JDK，只有JRE，缺少这些工具
- 可以考虑将工具打包进镜像，或使用
docker exec进入容器 - 在K8s中，可以使用
kubectl cp将工具复制到容器中
4.3 安全限制与解决方案
某些生产环境可能限制直接使用这些工具，可以：
- 通过JMX远程连接
- 使用jattach工具(需要SA权限)
- 配置JMX端口并添加安全策略
5. 常见问题速查表
| 问题现象 | 首选工具 | 关键检查点 |
|---|---|---|
| CPU使用率高 | jstack + top | 查找运行中的线程及执行栈 |
| 应用无响应 | jstack | 查找BLOCKED或WAITING状态的线程 |
| 内存持续增长 | jmap + jstat | 对象直方图 + GC统计 |
| 频繁Full GC | jstat | FGC计数 + 老年代使用率 |
| 类加载异常 | jstat | 查看Loaded/Unloaded class计数 |
| 方法编译性能问题 | jstat | 查看Compiled/Invalidated方法计数 |
6. 性能调优实战案例
去年我们遇到一个电商系统在大促期间频繁卡顿的问题。通过以下步骤最终定位到问题：
- 先用jstat发现Young GC非常频繁，几乎每秒2-3次
- jmap显示新生代对象中90%都是同一种DTO对象
- 分析线程栈发现有个循环在频繁创建这些对象
- 最终发现是日志打印时JSON序列化导致的临时对象暴涨
- 解决方案是改用更高效的序列化方式，并调整年轻代大小
这个案例让我深刻体会到，这些基础工具组合使用能解决看似复杂的问题。关键是要掌握工具的使用场景，并学会解读数据背后的含义。
7. 工具链的扩展与集成
虽然JRE自带工具很强大，但我们也需要与其他工具配合：
- 结合Arthas进行动态诊断
- 使用async-profiler进行更精确的CPU分析
- 将jstack输出导入在线分析工具(如fastthread.io)
- 用VisualVM分析堆转储文件
我个人的工作流程是：先用JRE工具快速定位问题范围，再用高级工具深入分析。这样既保证了响应速度，又不失分析的深度。