通常，我使用的内容
ParseHeapDump.sh包含在Eclipse Memory
Analyzer中，并在此处进行了描述，并将其添加到功能更强大的服务器上（通过linux
.zip发行版下载并复制，然后在其中解压缩）。与从GUI解析堆相比，shell脚本所需的资源更少，此外，您可以在具有更多资源的强大服务器上运行它（您可以通过
-vmargs-Xmx40g -XX:-UseGCOverheadLimit在脚本最后一行的末尾添加类似内容来分配更多资源。例如，修改后，该文件的最后一行可能如下所示
./MemoryAnalyzer -consolelog -application org.eclipse.mat.api.parse "$@" -vmargs -Xmx40g -XX:-UseGCOverheadLimit
像这样运行
./path/to/ParseHeapDump.sh ../today_heap_dump/jvm.hprof
成功之后，它会在.hprof文件旁边创建许多“索引”文件。
创建索引之后，我尝试从中生成报告并将这些报告scp到本地计算机，并尝试查看是否可以仅凭此找到罪魁祸首（不仅是报告，还不是索引）。这是有关创建报告的教程。
报告示例：
./ParseHeapDump.sh ../today_heap_dump/jvm.hprof org.eclipse.mat.api:suspects
其他报告选项：
org.eclipse.mat.api:overview和
org.eclipse.mat.api:top_components
如果这些报告还不够，并且还需要进一步挖掘（例如，通过oql进行说明），我会将索引以及hprof文件scp到本地计算机，然后打开堆转储（索引位于与堆转储）与我的Eclipse
MAT GUI。从那里开始，它不需要太多的内存即可运行。
编辑： 我只是喜欢添加两个说明：
- 据我所知，只有索引的生成才是Eclipse MAT的内存密集型部分。获得索引后，您从Eclipse MAT进行的大部分处理将不需要那么多的内存。
- 在shell脚本上执行此操作意味着我可以在无头服务器上进行此操作（并且通常也可以在无头服务器上进行操作，因为它们通常是功能最强大的服务器）。而且，如果您有一台服务器可以生成该大小的堆转储，那么很可能，您还有另一台服务器也可以处理那么多堆转储。
