“Java进程死亡”；交换空间不足”；在主要GC期间，机器上剩余大量内存

因此，我使用VisualVM监视一个进程，并单击“执行GC”，该进程随后因错误而终止：

#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 4088 bytes for char in /BUILD_AREA/jdk6_24/hotspot/src/share/vm/utilities/stack.inline.hpp. Out of swap space?
#
#  Internal Error (allocation.inline.hpp:39), pid=1148, tid=1082808672
#  Error: char in /BUILD_AREA/jdk6_24/hotspot/src/share/vm/utilities/stack.inline.hpp
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.1-b02 mixed mode linux-amd64 )
# An error report file with more information is saved as:
# /net/bsrs78.pit.twosigma.com/d-1/local/eaMemory2-yao-bsrs78.pit.twosigma.com-db8rsnyc9-head-20110622-130721-31729-0/hs_err_pid1148.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

但在我这么做之前不久，我检查了机器，似乎还有足够的内存（以MB为单位显示的数字）：

在我看来，GC不太可能占用所有内存

这是一个问题，因为如果我只是让程序继续运行，在某个点上，它将最大化其分配的堆，然后尝试执行一个主要的GC，并以相同的方式结束。小GC看起来不错

这是怎么回事？为什么它会随着交换空间消息而消亡？请让我知道我是否可以做些什么来提供更多信息或进一步诊断此问题。我将非常感谢所有的帮助

谢谢

Edit1：我已经在上传了错误日志，值得一提的是，它对次要GC使用PS清除，对主要GC使用PS MarkSweep

<2> Edt2:同样，这个问题已经发生了很多次，在一个主要的垃圾收集过程中持续死亡——不管是通过VisualVM或是堆出来的，还是由JVM自己触发的。这似乎是VM的配置问题

可以找到另一个例子。通过减少分配给虚拟机的内存量，可以报告并修复相同的错误

---

我无法下载您的错误日志，但我建议尝试减少内存设置，看看是否有帮助。

谢谢大家的输入。事实证明，我们公司的系统（通过ulimit）对进程的虚拟内存量进行了限制，仅比请求的堆内存量高约1G。因此，当进程超出此限制时（显然，主GC将触发此限制），即使在机器上还有更多虚拟内存的情况下，进程也被拒绝提供更多内存（“OutofSwap”消息具有误导性！）。提高虚拟内存限制解决了问题。

您可以看到交换空间已耗尽，并且由于OOM（OutOfMemoryError）而发生崩溃 此问题已在6u25的JDK-6302804中解决

---

升级JVM可以避免这个问题。

另外，消息提到的错误报告文件中有什么？通常内存不足只会产生未检查的异常。如果虚拟机崩溃，那就太糟糕了。查看运行jvm的最小内存量；在许多系统上，它是128Mb。@bdonlan即100G，数字以MB为单位显示。我已经上传了错误日志。谢谢。啊，哎呀，那会有所不同：）@welkin，烫发机好像满了；你在里面卡住了什么？试着把它增加到

-XX:MaxPermSize=192m

。我见过很多JVM崩溃，但幸运的是，没有一个像“交换空间不足？”（un）这样的问题。我确实看到了这个问题，尽管“ulimit-d-v”显示它已经设置为无限。“。我理解减少堆数量背后的原因——为底层JVM编译器等留下更多内存。但是当机器报告仍有超过40G的内存时？这让我觉得这是一个不同的问题……您可能是对的，但您可以通过将堆大小减半来确保这不是问题，并查看它是否有效（除非您的应用程序不会以这种方式运行）。另一个选择是去看看发生了什么。我用25G重新运行，它又死掉了。查看gc日志，当主要gc即将开始时，它总是会消失：（您是否可以更新到最新版本。从日志中可以看到update 23和update 26。您可能在VM中发现了一个错误。看起来像update 25，包括几个垃圾收集器错误。似乎值得一试。

free -m
             total       used       free     shared    buffers     cached
Mem:         96869      60999      35869          0        363       4590
-/+ buffers/cache:      56045      40823
Swap:        10243         40      10203