我正在调查其中一个生产系统上的JVM崩溃，下面的hs_err_pid日志文件片段中的以下内存值代表什么？
Heap
par new generation total 1258624K, used 955445K [0x00000005c0000000, 0x00000006155b0000, 0x000000066aaa0000)
eden space 1118784K, 73% used [0x00000005c0000000, 0x00000005f1e52598, 0x0000000604490000)
from space 139840K, 98% used [0x000000060cd20000, 0x00000006153db100, 0x00000006155b0000)
to space 139840K, 0% used [0x0000000604490000, 0x0000000604490000, 0x000000060cd20000)
tenured generation total 2796224K, used 1745107K [0x000000066aaa0000, 0x0000000715550000, 0x00000007c0000000)
the space 2796224K, 62% used [0x000000066aaa0000, 0x00000006d52d4d90, 0x00000006c2e0c400, 0x0000000715550000)
compacting perm gen total 482944K, used 482943K [0x00000007c0000000, 0x00000007dd7a0000, 0x0000000800000000)
the space 482944K, 99% used [0x00000007c0000000, 0x00000007dd79fff0, 0x00000007dd7a0000, 0x00000007dd7a0000)
No shared spaces configured.
我关心的是“紧凑型烫发粉”的用法:这是指已分配的最大烫发粉堆已使用的百分比，还是最大堆使用的百分比，还是其他？提供的百分比似乎是已使用/总计的百分比，这是分配的总烫发量吗？由于我们的
-XX:MaxPermSize设置为1GB ...是否有任何有用的资源(Oracle whitepaper除外，后者未提及hs_err文件)来解释在JVM崩溃时转储的数据？
最佳答案
我从未找到能准确描述“comping perm gen”值的参考，但是我们自己的调查证明所报告的值为:
当前使用的PermGen /当前分配的PermGen
在我的问题示例中，这意味着已经为PermGen分配了482944K的内存，并且在GC时已使用了482943K的内存(99％)。我们的最大PermGen大小设置为1048576K(1GB)，因此收集过程中有大量保留的资源可供重新分配。
对于那些遇到类似问题的人，我们最终解决了我们的问题。在我们的案例中，结果证明这是一个使用了sun.misc.Unsafe类的第三方库，当使用不正确时，它就是notoriously "unsafe"。
在这种情况下，piece of logic for cloning objects将特定的ClassLoader传递给某些sun.misc.Unsafe操作以复制对象。在某些计算机上，通常以损坏状态创建复制的对象。当JVM尝试进行垃圾收集时，它最终将收获这些不良对象之一并崩溃。这总是引起我的问题中描述的错误。