我想弄清楚为什么Elasticsearch节点上的JVM堆使用率始终保持在80％以上。为了做到这一点，我通过运行一个堆转储
jmap.exe -heap:format=b 5348
（5348是进程ID）。然后，我可以使用VisualVM分析转储。
问题是jmap在进行转储时暂停了JVM，因此该节点基本上处于脱机状态约5分钟。
jmap
本文提出了一种更快的方法，该方法依赖于gdb在Linux 上使用coredump 。我已经尝试过WinDbg，它创建了一个核心转储，但是我无法在VisualVM中使用它。
gdb
Windows是否有类似的方法？如何在几秒钟而不是几分钟内完成堆转储？
在使用coredump以后WinDbg，您需要通过运行以下命令从中提取堆转储
WinDbg
jmap -heap:format=b "C:\Program Files\Java\...\bin\java.exe" core.mdmp
这可以脱机完成；无需与运行中的Java进程进行交互。然后，您将能够heap.bin在VisualVM中打开生成的文件。
heap.bin
或者，您可以获取班级直方图。它产生的速度比完整堆转储的速度快。
jmap -histo <PID>
它显示了其实例在堆中占据最大空间的类的列表。这些信息通常足以使您了解丢失内存的位置。
