一、为什么 Java 运维离不开监控¶

原笔记在 Tomcat 部署之后，继续讲了远程监控和故障案例，这个顺序很合理。
因为 Java 程序一旦上线，运维真正会遇到的问题通常不是“怎么启动”，而是：

• 性能为什么变差
• 线程为什么堵住
• 内存为什么涨高
• 系统负载为什么异常

所以监控和排障能力，是 Java 运维不可绕开的部分。

二、Tomcat 如何开启 JMX 远程监控¶

原笔记使用的是 JMX Remote 方案。
核心思路是在 catalina.sh 中增加启动参数：

CATALINA_OPTS="$CATALINA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=12345 \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.ssl=false \
-Djava.rmi.server.hostname=192.168.1.20"

这几个参数分别意味着：

• 开启远程监控
• 指定 JMX 端口
• 关闭认证
• 关闭 SSL
• 指定对外监听地址

修改后重启 Tomcat：

systemctl restart tomcat

然后通过进程查看，确认参数已经带进启动命令行。

三、如何验证 JMX 远程监控可用¶

原笔记采用的是 Windows 下的 jconsole 连接测试。
大致步骤是：

1、安装 JDK
2、打开 jconsole.exe
3、输入：

192.168.1.20:12345

4、在没有开启认证的情况下直接连接

如果能够看到内存、线程、类加载等信息，就说明远程监控已经打通。

这类方式虽然在生产里需要进一步加固，但作为实验和接入监控平台前的验证非常直观。

四、jps、jstack、jmap 分别是干什么的¶

原笔记把 Java 排障命令集中在一节中，全部都是以 j 开头的工具。

4.1 jps¶

jps 可以理解成 Java 版的 ps，用于查看 Java 进程。

例如：

jps -lvm | grep tomcat_8081

它适合：

• 快速找出 Java 进程 PID
• 区分不同的 Tomcat 实例或 Java 应用

4.2 jstack¶

jstack 用来查看 Java 进程内部的线程堆栈信息。

例如：

jstack 60853
jstack 60853 | grep -i state

原笔记特别强调了线程状态的观察价值，例如：

• RUNNABLE
• WAITING
• TIMED_WAITING

如果系统负载高、线程卡住、应用响应慢，jstack 往往是第一批要看的工具。

4.3 jmap¶

jmap 更偏向 JVM 内存与堆信息查看。

例如查看堆：

jmap -heap 60853

可以看到：

• 堆大小
• 新生代、老年代使用情况
• Metaspace 等信息

如果要进一步做离线分析，还可以导出堆转储：

jmap -dump:format=b,file=/root/jvm.dump 60853

这一步常用于后续交给开发或分析工具做深入检查。

五、MAT 为什么常和 jmap dump 配合出现¶

原笔记随后介绍了 MAT，也就是：

• Memory Analyzer Tool

它的典型用法是：

1、用 jmap 导出 jvm.dump 2、把文件下载到本地 3、用 MAT 打开分析

MAT 更适合：

• 分析内存对象占用
• 识别内存泄漏嫌疑
• 协助开发定位堆中异常对象

也正因为如此，原笔记特别提到：

• 这类分析往往需要和开发一起看

六、原笔记里的忙线程排查脚本解决了什么问题¶

原笔记还提供了一个脚本：

• show-busy-java-thread.sh

它的目标很明确：

• 找出 CPU 占用率最高的 Java 线程
• 再把这些线程对应的 jstack 堆栈打印出来

这类脚本特别适合：

• 系统负载升高
• 怀疑是某些 Java 线程在忙等、死循环或高计算占用

相比人工一条条命令排查，它能把：

• ps
• 线程 ID
• jstack

这些步骤串起来，显著提高故障定位效率。

七、系统负载高时的排查顺序该怎么走¶

原笔记最后对“Java 应用负载高”给出了一条比较完整的排查链路：

1、先通过监控发现告警
2、登录主机确认负载是否真的高
3、判断是 CPU、IO 还是其他资源问题
4、找到对应高负载进程
5、如果是 Java 进程，再看线程层面
6、必要时导出 JVM 堆并用 MAT 分析

涉及到的命令和工具包括：

• w
• uptime
• top
• ps aux
• iotop
• vmstat
• jps
• jstack
• jmap

这说明 Java 排障并不只是看 JVM，本质上仍然要先回到操作系统层做判断。

八、小结¶

Tomcat 和 Java 应用的监控排障，核心是从“进程 -> 线程 -> 内存”逐层深入。
原笔记这一部分最实用的地方在于把这些工具串成了一条能落地的排查路径：

• 先开好 JMX，便于远程监控
• 用 jps 找进程
• 用 jstack 看线程
• 用 jmap 看内存
• 用 MAT 做深入分析

对 Java 运维来说，这套方法远比只会重启服务更重要。