在 Linux 环境下，精准监控 Tomcat 内存状态是保障 Java 应用稳定性的核心运维技能，这需要从JVM 配置参数和运行时实时数据两个维度入手，综合运用 ps、jstat、jmap 等命令行工具进行分析，通过掌握这些命令，运维人员不仅可以确认堆内存、非堆内存的分配上限，还能实时洞察垃圾回收（GC）频率与各分区的内存占用情况，从而快速定位内存泄漏或配置不当引发的性能瓶颈。
查看 JVM 启动配置与内存分配上限
在分析运行时数据之前,首先必须明确 Tomcat 进程启动时的内存配置上限，这是判断内存是否“超限”的基础，最直接的方法是通过查看操作系统的进程信息来获取启动参数。
使用 ps 命令结合 grep 可以快速筛选出 Tomcat 进程及其启动参数：
ps -ef | grep java | grep tomcat
在输出结果中,重点关注 -Xms、-Xmx、-Xmn 以及 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 这几个关键参数。
- -Xms：表示 JVM 初始堆内存大小。
- -Xmx：表示 JVM 最大堆内存大小，在生产环境中，通常建议将 -Xms 与 -Xmx 设置为相同值，以避免 JVM 在运行过程中动态调整堆大小带来的性能损耗。
- -Xmn：表示堆中年轻代的大小。
- -XX:MaxMetaspaceSize：表示元空间（方法区）的最大容量，这在 Java 8 及以上版本中替代了原有的永久代。
如果输出过长,可以使用 awk 或 xargs 进行格式化处理，以便更清晰地读取配置，检查 catalina.sh 或 setenv.sh 脚本文件也是确认配置源头的必要步骤，确保重启后配置依然有效。
实时监控堆内存与垃圾回收状态
配置只是静态的界限,真正的内存波动发生在运行时，JDK 自带的 jstat 工具是监控 JVM 内存统计数据的首选利器，它能够以极高的频率输出内存各分区的使用情况，且对性能影响极小。
执行以下命令可以监控 Tomcat 的堆内存使用情况（假设进程号为 12345）：
jstat -gcutil 12345 1000 10
该命令表示每隔 1000 毫秒（1秒）输出一次统计信息，共输出 10 次，输出列包含了几个核心指标，理解这些指标对于分析内存状况至关重要：
- S0 和 S1：分别表示 Survivor 区的当前使用比例，这两个区会根据 GC 算法在 From 和 To 角色间切换。
- E：表示 Eden 区（伊甸园区）的使用比例。Eden 区是对象创建的摇篮，如果该区域长期处于 100% 状态，说明对象创建速率过快或 Minor GC（新生代 GC）回收效率低。
- O：表示 Old 区（老年代）的使用比例，这是监控的重中之重，Old 区比例持续攀升并接近 100%，往往意味着存在内存泄漏或堆内存上限不足，即将触发 Full GC。
- M：表示 Metaspace（元空间）的使用比例，如果此比例持续上升，通常是因为加载了大量的动态类。
- YGC 和 YGCT：Young GC 的次数和时间，通过计算 YGCT / YGC 可以得出平均 Minor GC 耗时，评估新生代回收效率。
- FGC 和 FGCT：Full GC 的次数和时间。Full GC 会导致 STW (Stop-The-World)，即系统暂停，FGC 频繁发生，必须立即排查，这通常是严重的性能问题信号。
深入分析堆内存对象分布
当发现 Old 区占用异常过高时，仅知道百分比是不够的，我们需要知道究竟是哪些对象占用了内存。jmap 工具便派上了用场。
-
查看堆内存对象统计信息
使用以下命令可以生成堆中对象的统计直方图，按对象数量和占用大小排序：jmap -histo:live 12345 | head -n 20
输出结果将列出占用内存最多的前 20 个类，通过分析这些类名，可以快速定位到业务代码中是否存在大量未释放的集合（如 ArrayList、HashMap）或自定义的大对象。
live参数表示只统计存活对象，这会触发一次 GC，有助于分析真正的内存占用。 -
导出堆转储文件
为了进行更深入的离线分析（如使用 MAT 或 VisualVM），可以将当前堆内存快照导出为文件：jmap -dump:format=b,file=heap_dump.hprof 12345
注意：导出 hprof 文件会导致进程暂停，且文件大小通常与堆内存配置相当（可能达到数 GB），因此在生产环境操作时需谨慎评估业务影响。
结合系统级命令监控物理内存占用
除了 JVM 内部的堆内存，Linux 操作系统视角下的内存占用同样重要，Tomcat 进程占用的物理内存（RSS）不仅包含 Java 堆，还包含堆外内存，如线程栈、代码缓存、直接内存以及 JVM 自身的库文件开销。
使用 top 或 pidstat 命令可以查看进程的 RES（常驻内存）和 VIRT（虚拟内存）。
top -p 12345
或者
pidstat -r -p 12345 1 5
专业见解：很多运维人员会发现 top 显示的 RES 远大于 -Xmx 的配置值，这是正常现象，因为 RES = 堆内存 + 元空间 + 线程栈 + 直接内存 + 共享库，如果堆外内存占用过高，可能是由于使用了 NIO（Netty 等）分配了大量 Direct Buffer，或者是创建了过多的线程，需要调整 -XX:MaxDirectMemorySize 或限制应用层的线程创建数量。
常见内存问题的排查思路
在实际运维中,遇到内存报警时，应遵循“先配置后运行，先堆内后堆外”的原则。
- 频繁 Full GC：首先检查
-Xmx是否过小，如果配置合理，则使用jmap -histo分析老年代对象，确认是否存在内存泄漏，如果是内存泄漏，必须重启应用并联系开发人员修复代码；如果是内存不足，则需扩容。 - OutOfMemoryError: Metaspace：这通常是因为动态代理、JSP 编译或反射调用过多，解决方案是调大
-XX:MaxMetaspaceSize，并检查是否取消了-XX:+UseClassMetaspace等废弃参数。 - 进程被系统 Kill：Linux OOM Killer 会在系统物理内存+Swap 耗尽时杀掉占用内存最大的进程，此时查看
/var/log/messages或dmesg可以看到 OOM Killer 的日志，这通常是因为堆外内存失控或机器上运行了过多其他进程。
相关问答
Q1：为什么在 Linux top 命令中看到的 Tomcat 进程 RES（物理内存）占用比配置的 -Xmx 最大堆内存还要大？
A： 这是一个非常普遍的误解，JVM 进程占用的总物理内存不仅仅只有 Java 堆，RES 包含了 Java 堆、元空间、代码缓存、GC 算法本身的数据结构、每个线程的栈空间以及 JVM 可执行文件和依赖的 C 库占用的内存，如果应用使用了 NIO 框架（如 Netty、RocketMQ），还会分配大量的直接内存，这部分内存也是堆外的，不受 -Xmx 限制，但会计入进程的 RES 中，RES 大于 -Xmx 是完全正常的，通常大出 20%-50% 都在合理范围内。
Q2：如何在不重启 Tomcat 的情况下，临时排查当前的 CPU 飙高是否由内存垃圾回收（GC）导致？
A： 可以使用 jstat -gcutil 命令持续观察，CPU 飙高期间，观察到 FGC (Full GC) 次数在急剧增加，或者 YGCT/YGC (单次 Young GC 耗时) 突然变大，那么可以断定 CPU 飙高是由频繁的 GC 或长时间的 STW (Stop-The-World) 导致的，结合 jstack 命令查看线程堆栈，如果看到很多线程处于 “VM_Thread” 或等待 GC 监视器锁的状态，则进一步证实了这一判断，这通常意味着内存配置不足或存在严重的内存泄漏，导致系统资源耗尽在垃圾回收上。
