如何监控和调优JVM的内存使用情况？

原创已于 2025-08-24 02:26:47 修改 · 597 阅读

CC 4.0 BY-SA版权

文章标签：

于 2025-08-24 02:23:32 首次发布

13 篇文章

订阅专栏

监控和调优 JVM 内存使用是保障 Java 应用稳定性和性能的核心手段，需要结合监控工具、关键指标分析和针对性调优策略。以下是具体的实施方法：

监控的目标是掌握内存使用趋势、GC 行为、线程状态等，为调优提供数据依据。

根据场景选择工具（命令行工具适合服务器环境，可视化工具适合本地分析）：

工具类型	工具名称	核心用途
命令行工具	`jps`	查看当前运行的 JVM 进程 ID（如`jps -l`显示进程 ID 和主类）。
	`jstat`	实时监控 GC 统计信息（如堆内存使用、GC 次数 / 耗时）。
	`jmap`	生成堆内存快照（用于分析对象分布）、查看堆配置（如`jmap -heap <pid>`）。
	`jstack`	导出线程栈信息（排查线程阻塞、死锁，辅助分析内存使用异常）。
	`jconsole`	简易图形化工具（监控堆内存、线程、类加载，适合快速排查）。
可视化工具	`VisualVM`	全能工具（集成监控、堆快照分析、GC 日志查看，支持插件扩展）。
	`MAT（Memory Analyzer）`	深度分析堆快照（定位内存泄漏、大对象，生成内存泄漏报告）。
	`GCEasy`	在线 / 离线分析 GC 日志（可视化 GC 频率、停顿时间，生成优化建议）。
APM 工具	`Arthas`	阿里开源诊断工具（动态查看内存、GC、线程，无需重启应用）。
	`Prometheus + Grafana`	分布式环境下的长期监控（结合`jmx_exporter`采集 JVM 指标，绘制趋势图表）。

需重点关注以下指标，判断内存使用是否健康：

堆内存指标：
- 年轻代（Eden、S0、S1）和老年代的使用率（是否持续增长至满）；
- 对象晋升速率（短期对象是否频繁进入老年代）。
GC 指标：
- Minor GC（年轻代回收）：频率（如每秒几次）和单次耗时（如平均 50ms）；
- Full GC（老年代回收）：频率（如每小时几次，过于频繁则异常）和单次耗时（如超过 1s 可能影响服务）；
- GC overhead（GC 耗时占总运行时间的比例，超过 20% 需警惕）。
元空间指标：
- 元空间使用率（是否持续增长，可能因类加载过多导致 OOM）。
线程指标：
- 线程总数（是否超过预期，可能导致栈内存耗尽）；
- 阻塞 / 等待线程数（是否有死锁、资源竞争）。
异常指标：
- 内存溢出日志（OutOfMemoryError）、栈溢出（StackOverflowError）的出现频率和触发场景。

调优需遵循 “监控→分析→调整→验证” 的闭环流程，避免盲目修改参数。

根据应用场景确定优先级：

基于监控数据，识别典型问题并定位根源：

问题场景	特征表现	可能原因	分析工具 / 方法
频繁 Minor GC	年轻代使用率快速达满，Minor GC 每秒数次	年轻代过小；短期对象创建过快	`jstat -gc <pid> 1000`（实时看 GC 频率）
频繁 Full GC	老年代使用率持续增长，Full GC 几分钟一次	内存泄漏；老年代过小；对象过早晋升	堆快照（`jmap -dump`）+ MAT 分析
Full GC 耗时过长	单次 Full GC 超过 1s，服务超时	老年代过大；GC 收集器选择不当（如 Serial GC）	GC 日志（`-XX:+PrintGCDetails`）
元空间 OOM	抛出`OutOfMemoryError: Metaspace`	动态生成类过多（如反射、CGLIB）；元空间上限过低	`jstat -gcmetacapacity <pid>`
线程创建失败	抛出`OutOfMemoryError: unable to create new native thread`	线程栈过大（`-Xss`）；总线程数过多	`jstack <pid>`查看线程数
内存泄漏	老年代使用率持续上升，Full GC 后不下降	无用对象被长期引用（如静态集合未清理）	MAT 分析堆快照（查找支配树大对象）

根据问题场景调整参数或优化代码：

堆内存调优：
- 若频繁 Minor GC：增大年轻代（如调小-XX:NewRatio，或直接设置-XX:MaxNewSize）；
- 若频繁 Full GC 且无泄漏：增大老年代（调大-XX:NewRatio，或直接增大-Xmx）；
- 若对象过早晋升：调大 Survivor 区（减小-XX:SurvivorRatio），或提高晋升年龄（-XX:MaxTenuringThreshold=15）。
GC 收集器调优：
- 低延迟需求（如 Web 服务）：使用 G1（-XX:+UseG1GC）并限制停顿时间（-XX:MaxGCPauseMillis=200）；
- 高吞吐量需求（如批处理）：使用 Parallel GC（-XX:+UseParallelGC）；
- 超大堆场景（如 32GB+）：使用 ZGC（-XX:+UseZGC）或 Shenandoah GC，避免 Full GC 卡顿。
元空间调优：
- 若频繁元空间 GC：调大初始阈值（-XX:MetaspaceSize=128m）；
- 若元空间 OOM：调大上限（-XX:MaxMetaspaceSize=512m），并优化类加载（如减少动态代理生成）。
线程栈调优：
- 若栈溢出（StackOverflowError）：增大-Xss（如-Xss1m）；
- 若线程创建失败：减小-Xss（如-Xss256k），并控制线程池大小。
内存泄漏修复：
- 通过 MAT 的 “支配树” 功能定位泄漏对象（如未清理的HashMap、ThreadLocal）；
- 修复代码：移除无用引用（如remove()而非clear()）、使用弱引用（WeakHashMap）等。

调整后需对比优化前后的指标：

开启 GC 日志：通过参数记录 GC 详情，为分析提供依据：

bash
```
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:/path/to/gc.log
```
（JDK 9 + 使用统一日志格式：-Xlog:gc*:file=/path/to/gc.log:time）
建立性能基线：在应用稳定期记录正常指标（如 GC 频率、堆使用率），作为调优对比的基准。
避免过度调优：若应用性能达标（如 GC 停顿 < 100ms，无 OOM），无需盲目调整参数，保持默认配置可能更稳定。