JVM（64位1.5.0._22）在GCTaskThread时崩溃

Question

我们的一台开发服务器不时崩溃，而且报告看起来非常相似。我们认为这是由于内存不足造成的，但我们想要验证一下。你们能帮助我们进行此过程吗？以下是hs_err文件中的相关信息。

谢谢！ Yon

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0x00002b84b6dee37c, pid=4196, tid=1081399616
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.5.0_22-b03 mixed mode)
# Problematic frame:
# V  [libjvm.so+0x5b437c]
#

---------------  T H R E A D  ---------------

Current thread (0x000000005db44970):  GCTaskThread [id=4200]

siginfo:si_signo=11, si_errno=0, si_code=128, si_addr=0x0000000000000000


Heap
 PSYoungGen      total 291968K, used 291760K [0x00002aaada600000, 0x00002aaaec400000, 0x00002aaaec400000)
  eden space 291136K, 100% used [0x00002aaada600000,0x00002aaaec250000,0x00002aaaec250000)
  from space 832K, 75% used [0x00002aaaec250000,0x00002aaaec2ec288,0x00002aaaec320000)
  to   space 896K, 21% used [0x00002aaaec320000,0x00002aaaec350000,0x00002aaaec400000)
 PSOldGen        total 583680K, used 385757K [0x00002aaab6c00000, 0x00002aaada600000, 0x00002aaada600000)
  object space 583680K, 66% used [0x00002aaab6c00000,0x00002aaace4b7438,0x00002aaada600000)
 PSPermGen       total 116736K, used 116682K [0x00002aaaaac00000, 0x00002aaab1e00000, 0x00002aaab6c00000)
  object space 116736K, 99% used [0x00002aaaaac00000,0x00002aaab1df2b78,0x00002aaab1e00000)


---------------  S Y S T E M  ---------------

OS:CentOS release 5.3 (Final)

uname:Linux 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64
libc:glibc 2.5 NPTL 2.5 
rlimit: STACK 10240k, CORE 0k, NPROC 16384, NOFILE 99999, AS infinity
load average:22.73 19.62 19.08

CPU:total 4 em64t

Memory: 4k page, physical 2059636k(196532k free), swap 128512k(120972k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (1.5.0_22-b03) for linux-amd64, built on Oct  9 2009 01:32:14 by java_re with gcc 3.2.2 (SuSE Linux)

time: Fri Aug  5 03:57:27 2011
elapsed time: 27420 seconds

- Yon

---

升级到现代的1.6.x JVM是一个明显（而且明智）的建议。 - skaffman

不可能的，这是一个已经部署在众多客户那里的产品。还有别的想法吗？ - Yon

你的JVM崩溃了。问题出在JVM上。你正在使用旧的JVM。这个问题可能已经在更新的JVM中得到修复。这可能不是你想要的答案，但结论是不可避免的。 - skaffman

过去没有发生过这种情况，这是相当新的，使用了相同的服务器、JVM等。因此，我们可能以某种方式触发了这种行为。难道没有已知的问题列表，以及如何避免这些问题吗？ - Yon

Answer 1

作为一种解决方法，您可以通过“-XX：PermSize = 256m -XX：MaxPermSize = 256m”增加永久代的大小。这并不能完全解决问题，但可以延迟崩溃。

或者您可以尝试使用其他的垃圾回收策略，如并发垃圾回收。

- Kuai Wei

Answer 2

内存不足不应该导致JVM崩溃。如果发生了这种情况，那就是JVM的一个bug，唯一真正的解决方法是升级。

我能想到的唯一可能是“你的错”的情况是：

• 你的代码或某个第三方库正在使用本地代码库进行某些操作，并且该代码存在缺陷，

• 你的JVM安装已经被微妙地破坏了，或者

• 你的机器上有一个间歇性的硬件故障。

---

如果你怀疑问题是内存不足导致的，可以开启GC日志记录来确认。或者你可以尝试调整堆大小和其他设置，希望能解决这个问题。

---

在某个时候，您将不得不告诉客户您不能再为旧的（生命周期结束的）JVM安装提供支持。如果这是一个JVM Bug（正如我们所怀疑的那样），那么除非您/您的客户愿意付给甲骨文大笔支票以获得支持，否则很难得到修复。

- Stephen C

---

我们将在2012年2月转向Java 6。上面的报告显示Eden空间已满100％，PermGen已满99％，而故障出现在GCThread上。我们真的是第一个遇到这个问题的人吗？ - Yon

@Yon - "我们是不是真的是唯一遇到这个问题的人？" 可能不是。但最好的解决方法是升级。 - Stephen C