问题标签 [jcmd]

我正在尝试使用以下 2 个命令进行堆转储

1. jcmd $pid GC.heap_dump /tmp/filename.dump
2. jmap -dump:format=b,file=/tmp/filename.dump $pid

jcmd 产生的文件大小约为 300M，而 jmap 产生的文件大小约为 1.4G。为什么这些大小不同，我们在 jmap 中是否有任何其他信息？我在 jcmd 中缺少一些参数吗？

JDK 是 1.8.0_162

Xms 和 Xmx 是 4G

我的一项服务陷入僵局，无法打印堆栈信息。有没有办法解决问题？

由于 groovy 的东西，我们最近一直在为我们的应用程序遭受元空间 OOM，但是，我设法缓存已编译的脚本以阻止它现在发生。

以前，该进程每天至少崩溃一次。自从我应用修复程序以来，它至少运行了 4 天。为了再次确认修复确实有效，我使用jcmd Metaspace.dump转储了元空间

但是，我在阅读元空间转储时遇到问题，我相信关键信息在下面粘贴的头部。我不知道类空间和非类空间之间的区别以及我的进程已经提交了多少元空间。所以这里需要帮助，在此先感谢！

如果有必要，我可以附上完整的转储文件。但在我看来，它们只是内存块分配地址。

我们正在监控 jvm 指标，如堆、元空间、线程和 gc 计数，我们能够将这些指标推送到监控服务器，如 prometheus。同样，我们想跟踪 Java 本机内存指标（jcmd VM.sumary 的输出）。我的问题是，是否可以通过调用任何 jvm 运行时类来获取这些指标？

我目前正在调查压缩类空间问题。我知道问题出在哪里，但在调查时，我注意到jstat -gc ...并jcmd ... GC.heap_info给出了不同数量的元空间和压缩类空间容量和使用情况：

堆容量的数字似乎大致匹配（幸存者、伊甸园和老一代的所有容量都同意）。堆使用数字不完全匹配，但我不希望它们匹配；jstat在这里大约一秒钟后被收集jcm。但是元空间数字全部关闭，jstat数字通常略低于jcmd数字。我重新运行了这两个命令以确认调用之间没有发生类加载，实际上，这两个命令都为元空间编号提供了与以前相同的输出。

这里发生了什么？他们测量这些数字的方式是否略有不同？哪个更准确？

运行时信息：

使用jdk1.8.0_152我正在尝试追踪我的 java 程序的哪一部分使用的内存最多（主要在堆中）

使用top我看到整个过程使用了大约 1.109G 的剩余内存

使用jcmd {PID} VM.native_memory我看到总保留是 4704896 KB，提交是大约 1290820 KB。已提交的内存略多于剩余内存，但我读过并非所有已提交的内存都可以分页到实际内存，所以我不太担心这种差异

我现在主要关心的是我VM.native_memory使用时堆内存使用量和总堆使用量之间的差异jcmd {PID} GC.class_histogram

我还尝试比较使用的堆使用情况jstat -gc {PID}，得到的结果类似于GC.class_histogram

根据GC.class_histogramand jstat -gc，堆使用量约为 250MB，但使用VM.native_memory堆使用量（在该Java Heap部分中提交）约为 1000000KB（略小于 1GB），但实际 RSS 内存似乎更接近于VM.native_memory

我现在的猜测是VM.native_memoryJava Heap 包含尚未被垃圾收集的内存，但即使我运行垃圾收集，我看到jstat -gc急剧减少的结果VM.native_memory完全没有受到影响（尽管我听说用户手动调用垃圾收集不会总是导致完整的垃圾收集，但似乎至少这jstat -gc似乎与GC.class_histogram.

我听说的另一件事是，top当使用内存的进程释放它时，并不总是释放剩余内存，直到绝对需要释放该内存。

所以总结一下

1. 为什么显示与和VM.native_memory不同的堆内存使用情况？jstatGC.class_histogram
2. 我应该使用哪个指标来确定我的 java 进程正在使用多少内存？（考虑到剩余内存top可能并不总是反映实际使用情况）

我正在尝试使用以下命令在 CMD 中启用本机内存跟踪。

但收到如下错误：

可运行的程序或批处理文件。

我还尝试了以下命令：

但出现如下错误：

我正在尝试通过以下代码使用 jcmd 访问 NMT：

但是得到以下错误：

)

我正在调查 OutOfMemoryError: Compressed Class Space 问题。我认为，我找到了它的根本原因和解决方案（由 Hibernate Validator 方法调用的 JAXBContext.newInstance()：在用户提交的每个操作之后 buildValidatorFactory），但在我的研究中，我注意到一件令人困惑的事情。

我尝试运行 jcmd VM.native_memory 和 jstat -gc 来跟踪类提交大小和 CCSU（压缩类空间使用）：

和

我预计 NMT 中的“已提交类别”指标和 jstat 中的 CCSU 指标之间没有重大区别，但 jstat 显示的已用内存大约只有 1.72 MB，而已提交类别超过 24 MB。所以我生成了 GC.class_stats 统计数据，它显示 KlassBytes 大约是 1738616 B -> 1,739 MB - 所以它与 CCSU 中的 jstat 显示的值大致相同。我还发现其他元数据（如方法、常​​量等）占用了大约 14,44 MB（这与 mmap 中的值大致相同：committed=14720KB - 但我不知道这个数字是多少）。

那么剩下的部分在哪里呢？NMT 给出的数字到底是多少？

我尝试使用 jcmd 进行堆转储（来自 git bash 控制台窗口）：

但是，该文件似乎不存在：

我在哪里可以找到它？