java堆内存泄漏利用内存分析工具（Memory Analyzer Tool，MAT）分析

java堆内存泄漏利用内存分析工具（Memory Analyzer Tool，MAT）分析

可以，完全可以在 Windows 上执行。
生成 .hprof 文件、运行导致频繁 FGC 的 Java 代码以及使用 jmap/jcmd 等工具，在 Windows 上的操作逻辑与 Linux/macOS 基本一致，只是命令格式和路径分隔符略有不同。
以下是在 Windows 环境下操作的完整指南：

1. 前置准备

确保您的 Windows 机器上已安装 JDK (不仅仅是 JRE)，并且配置了环境变量 JAVA_HOME 和 PATH。
验证方法：打开 CMD 或 PowerShell，输入 java -version 和 javac -version
最简单且稳定的方法是：不断创建大对象并持有它们，强制填满老年代（Old Generation）。当老年代空间不足时，JVM 会频繁触发 Full GC 尝试清理，如果清理不掉（因为对象都被引用着），最终会导致 OOM 并生成 .hprof 文件。
以下是纯原生 Java 代码及 Windows 执行步骤：

2. 编译代码

编写代码 (无需任何第三方 jar 包)
新建一个文件 FgcGenerator.java，复制以下代码：

import java.util.ArrayList; import java.util.List; public class FgcGenerator { // 使用静态列表持有对象引用，防止它们被回收 private static final List<byte[]> memoryHog = new ArrayList<>(); public static void main(String[] args) throws InterruptedException { System.out.println(">>> 开始制造频繁 FGC 场景 (纯原生 Java)..."); System.out.println(">>> 策略：不断分配 2MB 大对象填入老年代"); int count = 0; try { while (true) { // 创建一个 2MB 的字节数组 // 如果 Survivor 区小于 2MB，该对象会直接进入老年代 byte[] bigObject = new byte[2 * 1024 * 1024]; // 填入列表，阻止 GC 回收 memoryHog.add(bigObject); count++; // 每分配 50 个对象 (约 100MB) 打印一次状态并提示 GC if (count % 50 == 0) { long usedMemory = (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / (1024 * 1024); System.out.println("已分配对象数: " + count + ", 当前堆使用: " + usedMemory + " MB"); System.out.println(">>> 手动触发 System.gc() 观察 FGC 频率..."); // 提示 JVM 进行 GC，此时由于老年代已满，极大概率触发 Full GC System.gc(); // 稍微休眠，让 GC 日志有时间输出，也避免 CPU 瞬间跑满 Thread.sleep(200); } } } catch (OutOfMemoryError e) { System.out.println("\n!!! 捕获到 OutOfMemoryError: " + e.getMessage()); System.out.println("!!! 如果配置了 -XX:+HeapDumpOnOutOfMemoryError，堆转储文件已生成。"); e.printStackTrace(); } } }

3. 在 Windows 上编译

打开 CMD 或 PowerShell，进入文件所在目录，执行：

javac FgcGenerator.java

4. 在 Windows 上运行 (关键步骤)

我们需要限制堆内存大小，以便快速复现 FGC 和 OOM。
准备工作：
确保存放 dump 文件的文件夹存在（例如 C:\temp）。

if not exist "C:\temp" mkdir "C:\temp"

执行命令：
复制以下命令到命令行运行（已配置好自动 dump 参数）：

java -Xms128m -Xmx128m ^ -XX:NewSize=32m -XX:MaxNewSize=32m ^ -XX:+HeapDumpOnOutOfMemoryError ^ -XX:HeapDumpPath=C:\temp\fgc_native_dump.hprof ^ -XX:+PrintGCDetails ^ -Xloggc:C:\temp\fgc_native_gc.log ^ FgcGenerator

参数详解：
-Xms128m -Xmx128m: 将最大堆限制为 128MB，这样只需分配几十个 2MB 的对象就会填满，快速触发 FGC。
-XX:NewSize=32m -XX:MaxNewSize=32m: 限制年轻代大小。因为我们的对象是 2MB，如果年轻代太小，大对象会直接进入老年代，加速 FGC 的发生。
-XX:+HeapDumpOnOutOfMemoryError: 核心，OOM 时自动生成 hprof。
-XX:HeapDumpPath=…: 指定 hprof 文件保存位置。
-Xloggc:…: 同时生成 GC 日志，您可以打开这个 txt 文件看到密密麻麻的 Full GC 记录。

5. 观察现象

1. 控制台输出：您会看到程序不断打印“已分配对象数…”，并且频繁出现 System.gc() 的提示。

2. GC 日志：程序运行几秒到几十秒后（取决于机器速度），控制台或 C:\temp\fgc_native_gc.log 文件中会出现大量的 Full GC 记录，且回收效果很差（因为对象都被 memoryHog 列表引用着，无法回收）。

3. 最终结果：

   • 程序抛出 java.lang.OutOfMemoryError: Java heap space。
   • 程序退出。
   • 检查 C:\temp 目录，您会发现生成了 fgc_native_dump.hprof 文件。

6. 如何验证是“频繁 FGC”导致的？

虽然 .hprof 本身不包含历史，但您可以结合生成的 GC 日志 (fgc_native_gc.log) 来证明：

• 用记事本打开 C:\temp\fgc_native_gc.log。
• 搜索 Full GC。
• 您会看到在短时间内（例如 1 秒内）发生了多次 Full GC，且每次回收后的内存占用依然很高。这就是典型的“频繁 FGC”现场。
• 然后用 MAT 打开 .hprof 文件，会发现 byte[] 数组占据了绝大部分内存，且被 java.util.ArrayList 引用，这就是导致 FGC 无法回收内存的元凶。

常见问题排查 (Windows)

• 报错 “Error: Could not create the Java Virtual Machine”：可能是 -Xms 和 -Xmx 设置得比机器可用物理内存还小（极少见），或者参数格式有误。请确保直接复制上面的命令块。
• 找不到 hprof 文件：检查 C:\temp 文件夹是否有写入权限，或者尝试将路径改为当前目录：-XX:HeapDumpPath=./fgc_dump.hprof。
• 程序运行太久不崩溃：如果您的机器内存很大，默认的堆可能不止 128M。请确保 -Xmx128m 参数生效（可以在程序启动的第一行打印 Runtime.getRuntime().maxMemory() 确认）。
  这个方法完全不需要下载任何额外的 jar 包，是最纯净的复现方式。
  

JAVA包下载:点击下载JDK 25.
MAT分析工具下载:点击下载MAT分析工具.

7. 解压配置java运行环境启动mat分析程序

Win+R输入SystemPropertiesAdvanced打开环境变量页面配置好点确定关闭页面即可
变量名：JAVA_HOME
变量值：解压jdk后的目录路径

配置Path：%JAVA_HOME%\bin

验证Java运行环境无异常
启动MAT内存分析工具