java - 更新到 Java 6 Update 14 后的 JVM 错误

Question

在将一些服务器更新为在 Java 6 update 14 上运行后，我遇到了一些奇怪的错误(可能每天一次)。

错误类似于

#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 1759920 bytes for Chunk::new. Out of swap space?
#
#  Internal Error (allocation.cpp:215), pid=26706, tid=317545360
#  Error: Chunk::new
#
# JRE version: 6.0_14-b08
# Java VM: Java HotSpot(TM) Server VM (14.0-b16 mixed mode linux-x86 )
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

奇怪的是，当前线程是编译器

  0x088a0800 JavaThread "CompilerThread1" daemon [_thread_blocked, id=26716, stack(0x12c7f000,0x12d00000)]
=>0x0889e400 JavaThread "CompilerThread0" daemon [_thread_in_native, id=26715, stack(0x12e55000,0x12ed6000)]

并且有足够多的可用内存:

堆

 PSYoungGen      total 256064K, used 93533K [0xa2cd0000, 0xb4290000, 0xb4290000)
  eden space 228352K, 31% used [0xa2cd0000,0xa72d6308,0xb0bd0000)
  from space 27712K, 78% used [0xb2780000,0xb3cd1150,0xb4290000)
  to   space 28032K, 0% used [0xb0bd0000,0xb0bd0000,0xb2730000)
 PSOldGen        total 2275584K, used 885858K [0x17e90000, 0xa2cd0000, 0xa2cd0000)
  object space 2275584K, 38% used [0x17e90000,0x4dfa8bf8,0xa2cd0000)
 PSPermGen       total 32128K, used 27819K [0x13e90000, 0x15df0000, 0x17e90000)
  object space 32128K, 86% used [0x13e90000,0x159bac50,0x15df0000)

我知道 JVM 崩溃很难调试，但我很好奇你们是否遇到过类似的问题 - 以及你们是如何解决这些问题的。

Answer 1

您遇到的错误不是 Java 代码错误，而是其中一个 Jit 编译器中的问题。当 Jit 启动时，它会占用一堆内存作为它实际执行的操作的内存)。此内存来自 native 堆。

对于真正感兴趣的人，这个错误最终会从 VM 中的此处发出(前面的 C++ 代码) http://www.google.com/codesearch/p?hl=en&sa=N&cd=1&ct=rc#aRIt9pqzOVI/src/share/vm/utilities/vmError.cpp&q=OutOfMemoryError%20Out%20of%20swap%20space&l=258不幸的是，它不是“真正的”OutOfMemoryError，它不会按照正常规则运行，您无法捕获它等等。

native (JNI/JNA) 方法可以直接从操作系统分配内存。 NIO直接使用内存，热点编译，还有其他

此内存是应用程序 native 堆的一部分(由 malloc 和 friend 管理的东西)，可能是您的应用程序用完了 native 堆导致发生这种情况，看看盒子上的整体内存，ulimit设置等。如果 JNI/JNA 代码能够耗尽应用程序为 native 代码提供的可用内存，它们也可以在某种程度上发挥作用。查看 NIO 的 DirectMappedBuffers，因为它们也可以从 Java 堆中窃取内存。

鉴于您刚刚更新，您很可能在其中一个 Jit 编译器中遇到了错误，GC 和 Jit 设置可能会影响这一点，因此请尝试将 jit(-client 更改为 -server 或 -server 为 -客户端)以查看是否有任何影响，您还可以尝试更改 GC 策略(但请记住，您正在更改 GC 策略以更改其与 jit 的交互，而不是修复 Java 内存问题)。

您还可以使用命令行标志 -Djava.compiler=NONE 完全关闭 Jit，但是由于这会删除任何 native 代码生成，因此会损害您的性能。

除此之外，如果您将 hprof 崩溃文件托管在某个地方，我或许可以为您提供更多想法。