为什么jmap和jcmd生成的堆转储大小不同？
我试图使用以下两个命令获取堆转储
- jcmd$pid GC.heap_dump /tmp/filename.dump
- jmap-转储：格式=b，文件=/tmp/filename.dump$pid
jcmd产生约300M的文件大小，jmap产生约1.4G的文件大小。为什么这些尺寸不同，我们在jmap中有其他信息吗？我在jcmd中遗漏了一些论点吗？
JDK是1.8.0_162
Xms和Xmx是4G
共有1个答案
默认情况下（当没有提供[选项]时），
JMAP转储了所有对象，JCMD只转储了活动对象。
使用JMAP命令：在使用该命令时，不需要指定任何内容，因为默认情况下，它会生成所有对象的堆转储。如果只需要活动对象，可以在JMAP中传递“-dump:live”选项。
使用JCMD命令：使用该命令时，必须传递-all选项。否则，它将请求一个完整的GC并只生成活动对象转储。
JCMD——没有任何对象状态选项——默认情况下，它只转储活动对象。
JMAP——没有任何对象状态选项——默认情况下会转储所有对象。
更多信息请参考这里
-
最近我遇到了一个gc问题，我用jmap转储堆。但不幸的是它不能正常工作； 我在转储之前运行jmap-histo3916 | more，结果是 然后我运行了"jmap-ump： form=b， file=heap.bin3916"，然后我用eclipse MemoryAnalyzer分析了heap.bin，生成了如下直方图 分析这两个结果，我发现dump中的对象都小于histo，char[]中的对象
-
我为我的Java web应用程序分配了一个最大值。由于一些内存泄漏，应用程序已经消耗了将近2 GB的分配内存。此时，我已经使用进行了内存转储。在一个实例中，堆转储大小接近>1.5GB，而在另一个实例中，堆转储大小<100 MB。这背后的原因是什么？
-
我正在经历内存泄漏，这里有一些细节。 在泄漏后， null null 我很惊讶顶部、堆转储大小和实际堆大小之间的差异。我猜测top和heap之间的区别是垃圾收集器堆和本地堆区域的可能性。但是，为什么堆转储文件大小和实际堆大小（来自eclipse MAT analyzer）会不同呢？ 对这个问题有什么见解吗？ 更新/回答 一些建议是使用jcmd(https://docs.oracle.com/jav
-
jmap帮助显示： ... ... 一旦我转储一个Tomcat（带有java参数-Xmx384m）堆： 我有一个300M的转储文件。 当我只使用活动对象转储其堆时： 我有一个120M的转储文件。 我对活物体的猜测可能是： > 年轻一代中的对象； 使用/引用/可访问且不会被收集的对象。 哪一个是对的？ 使现代化 我的猜测#2似乎是正确的，感谢Alexey Ragozin的解释（选项将导致完整GC）。
-
问题内容： 我们正试图在我们的Web应用程序中找到导致大量内存泄漏的元凶。我们在发现内存泄漏方面经验有限，但是我们发现了如何使用Eclipse MAT进行Java堆转储并对其进行分析。 但是，对于我们使用56 / 60GB内存的应用程序，堆转储的大小仅为16GB，而在Eclipse MAT中则更少。 语境 我们的服务器将Ubuntu 14.04上的Wildfly 8.2.0用于我们的Java应用程
-
我们正试图找到web应用程序中大内存泄漏的罪魁祸首。我们在查找内存泄漏方面的经验相当有限，但我们了解了如何使用创建java堆转储，并在Eclipse mat中对其进行分析。 但是，由于我们的应用程序使用56/60GB内存，堆转储的大小只有16GB，在Eclipse mat中就更少了。 对于我们的java应用程序，我们的服务器使用Ubuntu14.04上的Wildfly8.2.0，其进程使用了95%