JVM内存、GC与JConsole实战全解析：从理论到可视化的完整指南

于映雪 · 15 小时前

本文采用 "理论阐述 → JConsole验证 → 实战分析" 的三段式结构，确保每个抽象概念都能通过可视化工具得到直观验证。
第一部分：JConsole入门与环境准备

1.1 JConsole简介与启动

JConsole是JDK自带的图形化监控工具，可以实时监控JVM内存、线程、类加载等情况。
启动方式：

# 方式1：直接启动，然后连接本地或远程JVM
jconsole
# 方式2：启动时指定目标进程
jconsole <pid>

复制代码

（实操步骤1：启动演示程序）
先准备一个演示程序，用于后续的监控分析：

public class MemoryMonitorDemo {
private static List<byte[]> memoryHog = new ArrayList<>();
public static void main(String[] args) throws Exception {
System.out.println("演示程序启动，PID: " + ProcessHandle.current().pid());
System.out.println("在10秒内打开JConsole并连接此进程...");
// 等待JConsole连接
Thread.sleep(10000);
// 阶段1：模拟内存分配
simulateMemoryAllocation();
// 阶段2：模拟GC压力
simulateGCPressure();
Thread.sleep(30000); // 保持运行以便观察
}
private static void simulateMemoryAllocation() {
for (int i = 0; i < 10; i++) {
// 每次分配5MB
memoryHog.add(new byte[5 * 1024 * 1024]);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
private static void simulateGCPressure() {
// 创建大量短命对象，制造GC压力
for (int i = 0; i < 1000; i++) {
byte[] shortLived = new byte[2 * 1024 * 1024]; // 2MB短命对象
// 立即释放引用，让对象变成垃圾
shortLived = null;
if (i % 100 == 0) {
System.gc(); // 建议GC，但不保证立即执行
}
}
}
}

复制代码

编译运行：

javac -encoding UTF-8 MemoryMonitorDemo.java
java -Xmx100m -Xms100m -XX:+UseG1GC MemoryMonitorDemo

复制代码

第二部分：内存结构可视化分析

2.1 堆内存结构实战观察

理论回顾：

新生代：Eden + 2个Survivor区
老年代：长期存活对象
元空间：类元数据（JDK8+）

JConsole操作步骤：

启动JConsole并连接演示程序
进入"内存"标签页
选择"堆内存使用情况"

下图梳理了程序逻辑、关键内存区域与监控视图的对应关系：

图1：堆内存使用量 (概览)

图表含义：展示了整个堆内存的使用趋势。
程序关联：对应程序的两个主要阶段。
- 第一阶段（平稳上升） ：执行 simulateMemoryAllocation()，循环10次，每次分配5MB并持有引用。图表中堆内存从低点逐步增长到约 50-60 MB（10 * 5MB + 程序基础占用），这与代码逻辑完全吻合。
- 第二阶段（剧烈波动下降） ：执行 simulateGCPressure()，创建大量2MB的短命对象并立即弃用，同时每100次循环建议一次GC。图表呈现剧烈的锯齿状波动，这是G1垃圾收集器在工作，频繁回收新生成的垃圾对象。最后的陡降至低位，是程序运行结束，JVM进行最终清理（Final GC）。

图2：内存池 “G1 Eden Space”

图表含义：展示了G1垃圾收集器中年轻代的Eden区使用情况。
程序关联：绝大部分新创建的对象都会先分配在Eden区。
- 图表中频繁出现的、剧烈的、类似心跳的“锯齿波”，正是第二阶段GC压力测试的典型特征。每个“波峰”代表瞬间分配了大量2MB的短命对象（byte[] shortLived = new byte[2 * 1024 * 1024]）；紧接着的“波谷”代表一次Young GC（G1 Young Generation），回收了这些刚变成垃圾的对象。
- 第一阶段的内存分配（每次5MB）也可能在这里引发数次Young GC，但波动不如第二阶段剧烈。

图3：内存池 “G1 Old Gen”

图表含义：展示了G1垃圾收集器中老年代的使用情况。
程序关联：
- 在第一阶段，由于您分配的5MB数组被 memoryHog这个静态变量持续引用，它们是长期存活的对象。因此在几次Young GC后，这些对象会从年轻代晋升（Promote）到老年代。图表中老年代使用量从0开始阶梯式稳步增长，正反映了这个过程。
- 在最后阶段，程序运行结束，静态变量 memoryHog失效，老年代中的这些对象也不再被引用，因此在一次 Full GC / Mixed GC 中被彻底回收，图表线断崖式下跌至0。

图4：内存池 “G1 Survivor Space”

图表含义：展示了G1垃圾收集器中年轻代的Survivor区（存活区）使用情况。
程序关联：Survivor区用于存放在一次Young GC中存活下来的、但还未达到晋升年龄的对象。您的程序特点决定了很少有对象能在这里长期存活：
- 第一阶段的对象会直接晋升到老年代。
- 第二阶段的对象几乎都是“短命”的，会在Young GC中被直接回收。
- 因此，该图表显示Survivor区的使用量大部分时间极低，仅在极少数GC发生时可能有短暂的、少量的占用（图表中的小波峰），随后很快又被清空或晋升。

2.2 非堆内存分析

理论回顾：

方法区/元空间：类信息、常量池等
代码缓存：JIT编译后的本地代码
压缩类空间：类指针压缩

图5：非堆内存使用量 (概览)

图表含义：展示了非堆内存（主要是元空间 Metaspace）的使用趋势。
程序关联：非堆内存用于存储类元数据、常量池等。图表显示其使用量在程序运行期间基本保持稳定（约11MB），在程序最终结束时才被回收（骤降至接近0）。这符合预期，因为您的程序没有动态加载/卸载大量类。

图6：内存池 “Metaspace”

图表含义：展示了元空间的使用详情，它是图5“非堆内存”的主要组成部分。
程序关联：与图5解读一致。存储已加载的类信息。您的程序类数量固定，所以曲线平稳。程序结束时的下降与图2的非堆内存下降是同一事件。

图7 & 图8：内存池 “CodeHeap”

图表含义：展示了JVM中JIT编译器生成的本地代码的缓存区使用情况。profiled nmethods和 non-nmethods是不同编译状态和类型的代码存储区域。
程序关联：当JVM运行一段时间后，JIT编译器会将热点Java字节码编译成本地机器码，以提高执行速度。这些编译后的代码就存储在CodeHeap中。
- 图表中出现的波动，反映了在程序运行期间，JIT编译器在不断工作，编译新的方法，也可能淘汰一些不常用的编译代码。
- 程序结束时，这些内存被一并释放。

第三部分：GC机制可视化监控

3.1 GC算法与回收器选择

理论(详细信息可以看我上一篇帖子，里面有对理论知识的详细讲解)：
现代JVM采用分代收集理论，不同区域使用不同算法：
内存区域推荐算法特点适用场景新生代复制算法无碎片，高效对象朝生夕死老年代标记-整理空间利用率高对象存活时间长3.2 JConsole中的GC监控

启动演示程序时添加GC日志参数：

java -Xmx100m -Xms100m -XX:+UseG1GC -XX:+PrintGC -XX:+PrintGCDetails -Xloggc:gc.log MemoryMonitorDemo

复制代码

JConsole GC监控操作：

查看"概要"页签：查看JVM参数和正常运行时间
查看"内存"页签：实时观察各内存池变化
查看"VM摘要" ：了解GC收集器信息

（实操步骤2：GC活动对比实验）
创建两个终端，分别运行不同GC策略的程序：
终端1（G1GC）：

java -Xmx100m -Xms100m -XX:+UseG1GC -XX:+PrintGC GCDemo

复制代码

终端2（Parallel GC）：

java -Xmx100m -Xms100m -XX:+UseParallelGC -XX:+PrintGC GCDemo

复制代码

GCDemo.java：

public class GCDemo {
public static void main(String[] args) throws Exception {
List<byte[]> list = new ArrayList<>();
while (true) {
// 混合分配大小对象
for (int i = 0; i < 100; i++) {
list.add(new byte[1024]); // 1KB小对象
}
list.add(new byte[2 * 1024 * 1024]); // 2MB大对象
Thread.sleep(10);
// 模拟对象死亡
if (list.size() > 1000) {
list.subList(0, 500).clear();
}
}
}
}

复制代码

观察差异：

G1GC：停顿时间相对均匀，增量式回收
Parallel GC：吞吐量高，但停顿时间可能较长

第四部分：内存泄漏诊断实战

4.1 内存泄漏模式识别

理论： 内存泄漏的典型特征是老年代使用率持续上升，即使Full GC后也不释放。
创建内存泄漏演示：

public class MemoryLeakDemo {
private static Map<Key, String> cache = new HashMap<>();
static class Key {
private String id;
public Key(String id) { this.id = id; }
// 错误：没有重写equals和hashCode
// 正确的Key应该重写这两个方法
}
public static void main(String[] args) throws Exception {
System.out.println("内存泄漏演示开始...");
int count = 0;
while (true) {
// 每次使用不同的Key对象（但逻辑上相同）
Key key = new Key("key-" + (count % 100));
cache.put(key, "value-" + count);
if (count % 1000 == 0) {
System.out.println("Cache size: " + cache.size());
System.out.println("内存使用: " +
(Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / 1024 / 1024 + "MB");
}
count++;
Thread.sleep(10);
}
}
}

复制代码

运行：

java -Xmx50m -Xms50m -XX:+HeapDumpOnOutOfMemoryError MemoryLeakDemo

复制代码

4.2 使用JConsole检测内存泄漏

诊断步骤：

监控堆内存趋势
- 在JConsole中观察"已使用堆"曲线
- 内存泄漏特征：锯齿形上升（每次GC后最低点都比前一次高）
执行手动GC测试
- 点击"执行GC"按钮
- 观察内存回收效果：如果无法回收到稳定水平，可能存在泄漏
分析内存池分布
- 重点观察老年代：如果持续增长，说明长生命周期对象在积累

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

账号		自动登录	找回密码
密码			立即注册

JVM内存、GC与JConsole实战全解析：从理论到可视化的完整指南

相关帖子

签约作者

JVM内存、GC与JConsole实战全解析：从理论到可视化的完整指南

相关帖子

相关推荐

签约作者