垃圾收集器优先和JMap EOF错误
我们正在客户端的正式服堆上工作，以检测和解决内存泄漏。为此，我们定期使用jmap来收集必要的信息。
但上周我们无法进行转储，因为它触发了一个EOF错误并关闭了Tomcat实例。
我在网上搜索了一下，但找不到关于这个错误的任何具体信息。我们检测到，只有在使用Gc-First垃圾收集器算法时才会发生这种情况。
这是我们用来执行jmap的命令行：
jmap文件heap.bin
服务器上的Java版本：JDK 1.7.0\u 7 x64
有没有人已经面临过这种错误？可能缺少一些配置，或者需要java/jmap的补丁。
更新
我们收集了一些关于此错误的更多信息：
[root]# jmap -dump:format=b,file=heap.bin 7806
Dumping heap to /tmp/heap.bin ...
Exception in thread "main" java.io.IOException: Premature EOF
at sun.tools.attach.HotSpotVirtualMachine.readInt(HotSpotVirtualMachine.java:244)
at sun.tools.attach.LinuxVirtualMachine.execute(LinuxVirtualMachine.java:193)
at sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpotVirtualMachine.java:213)
at sun.tools.attach.HotSpotVirtualMachine.dumpHeap(HotSpotVirtualMachine.java:180)
at sun.tools.jmap.JMap.dump(JMap.java:241)
at sun.tools.jmap.JMap.main(JMap.java:140)
[root]#
注意：目标目录有超过500gb的可用空间
输出到catalina的错误。out（JVM转储错误）：
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f0269cc41c6, pid=7806, tid=139647231129360
#
# JRE version: Java(TM) SE Runtime Environment (7.0_40-b43) (build 1.7.0_40-b43)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.0-b56 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V [libjvm.so+0x58c1c6] DumperSupport::dump_field_value(DumpWriter*, char, unsigned char*)+0x1c6
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /opt/tomcat6/bin/hs_err_pid7806.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
共有1个答案
我可以通过使用一些其他选项来解决这个问题。
java版本“1.7.0\u 45”。
Java进程配置了第一个垃圾回收机制算法：
jmap -J-d64 -dump:live,format=b,file=<heap_dump_filename> <PID>
-
问题内容： 有人可以解释一下G1垃圾收集器的工作原理吗？我还无法在任何地方找到任何全面，易于理解的描述。 谢谢 问题答案： 收集器将堆分成固定大小的区域，并跟踪这些区域中的实时数据。它将一组指针（“记住的集”）保留在区域内和区域外。当认为有必要使用GC时，它将首先收集实时数据较少的区域（因此，“垃圾优先”）。通常，这意味着一步就可以收集整个区域：如果进入一个区域的指针数量为零，则无需对该区域进行标
-
Java 15 使 ZGC、Z 垃圾收集器成为标准功能。它是 Java 15 之前的一个实验性功能。它是低延迟、高度可扩展的垃圾收集器。 ZGC 是在 Java 11 中作为一项实验性功能引入的，因为开发人员社区认为它太大而无法提前发布。 即使在机器学习应用程序等海量数据应用程序的情况下，ZGC 也具有高性能和高效工作。它确保在处理数据时不会因垃圾收集而长时间停顿。它支持 Linux、Window
-
Java 15 使 ZGC、Z 垃圾收集器成为标准功能。它是 Java 15 之前的一个实验性功能。它是低延迟、高度可扩展的垃圾收集器。 ZGC 是在 Java 11 中作为一项实验性功能引入的，因为开发人员社区认为它太大而无法提前发布。从那时起，对这个垃圾收集做了很多改进，例如 - 并发类卸载 取消提交未使用的内存 支持班级数据共享 NUMA 多线程堆Pre-touch 最大堆大小限制从 4 T
-
问题内容： 是否有可能使Go中的垃圾收集器处理并释放通过C代码分配的内存？抱歉，我之前没有使用过C和cgo，因此我的示例可能需要澄清。 假设您有一些要使用的C库，并且该库分配了一些需要手动释放的内存。我想做的是这样的： 当Go运行时中没有对* Stuff的引用时，垃圾收集器是否可以调用Stuff.Free（）？ 我在这里有意义吗？ 也许更直接的问题是：是否有可能通过编写一个在该对象的引用为零时运行
-
Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经有但以后不再拥有 Owner 了。 注意：垃圾收集是 beta 特性，在 Kubernetes 1.4 及以上版本默认启用。 Owner 和 Dependent 一些 Kubernetes 对象是其它一些的 Owner。例如，一个 ReplicaSet 是一组 Pod 的 Owner。具有 Owner 的对象被称为是 Owner
-
问题内容： 我从带有node.js的线程垃圾收集中学到了node.js使用世代GC。 我通常使用循环对象引用（最终我都会删除/确保超出范围），并想知道node.js是否能很好地处理它们。所以例如。如果使用参考完成。计数，会有一个问题，所以我想知道这个节点有多好。 一些使用场景： 对于每个http请求，我创建一个带有lambda的setTimeout，该lambda可能引用了范围对象。作用域对象还引