为什么jmap-histo的结果不同于jmap-转储
最近我遇到了一个gc问题，我用jmap转储堆。但不幸的是它不能正常工作；
我在转储之前运行jmap-histo3916 | more，结果是
num #instances #bytes class name
----------------------------------------------
1: 1784198 733117168 [C
2: 12210014 390720448 java.util.concurrent.ConcurrentHashMap$Node
3: 11908601 285806424 java.lang.Long
4: 11884602 285230448 java.lang.Double
5: 545 86335608 [Ljava.util.concurrent.ConcurrentHashMap$Node;
6: 12405 65677584 [I
7: 1735496 41651904 java.lang.String
然后我运行了"jmap-ump： form=b， file=heap.bin3916"，然后我用eclipse MemoryAnalyzer分析了heap.bin，生成了如下直方图
Class Name | Objects | Shallow Heap | Retained Heap
-----------------------------------------------------------------------------------------
java.util.concurrent.ConcurrentHashMap$Node | 12,207,879 | 390,652,128 |
java.lang.Long | 11,889,204 | 285,340,896 |
java.lang.Double | 11,884,164 | 285,219,936 |
java.util.concurrent.ConcurrentHashMap$Node[]| 347 | 86,311,832 |
char[] | 1,659,912 | 50,128,128 |
java.lang.String | 1,659,062 | 39,817,488 |
-----------------------------------------------------------------------------------------
分析这两个结果，我发现dump中的对象都小于histo，char[]中的对象要少得多，但为什么呢？当运行“jmap-dump”命令时，jmap是否会触发一个小gc？
共有1个答案
jmap不触发GC，除非您指定： live选项。没有此选项，直方图将包含无法访问的对象。
然而，默认情况下，内存分析器在解析堆转储时删除不可到达的对象。尽管也可以用内存分析器计数不可到达的对象。
-
我试图使用以下两个命令获取堆转储 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
-
JMAP 全称是 JSON 邮件访问协议。新基于 JSON 的 API 用于实现与邮件服务器之间的邮件同步，可用于替换 IMAP。如果服务器支持 IMAP ，很容易就可以扩展对 JMAP 的支持。
-
jmap-perl 是 JMAP 代理服务器的 Perl 实现，Perl JMAP 后端可以与 IMAP 和 SMTP 服务器通许，允许在邮件系统上替换 JMAP 接口。为了高效，初始化实现要求所有服务器支持 CONDSTORE 扩展(RFC4551/FRC7162)。提供一个独立的 Gmail 后端，因为 Gmail 有原生服务端线程支持。
-
JMAP-JS 是 JMAP 邮件，联系人和日历模型的 JavaScript 实现，是 JMAP 的 JavaScript 客户端。
-
jmap帮助显示： ... ... 一旦我转储一个Tomcat（带有java参数-Xmx384m）堆： 我有一个300M的转储文件。 当我只使用活动对象转储其堆时： 我有一个120M的转储文件。 我对活物体的猜测可能是： > 年轻一代中的对象； 使用/引用/可访问且不会被收集的对象。 哪一个是对的？ 使现代化 我的猜测#2似乎是正确的，感谢Alexey Ragozin的解释（选项将导致完整GC）。
-
问题内容： 我们有一个应用的公开测试版，偶尔会导致堆空间溢出。JVM通过休假来做出反应。 为了分析这一点，我想在内存出现故障的时候查看一下。Java不想让我这样做。该进程仍在内存中，但似乎未被视为Java进程。 有问题的服务器是Debian Lenny服务器Java 6u14 问题答案： 解决方案非常简单。我以root用户身份运行jmap，但必须以启动jvm的用户身份运行它。我现在要羞愧地隐藏我的