JVM（64 位 1.5.0._22）在 GCTaskThread 崩溃
我们的一台开发服务器时不时地崩溃，报告看起来非常相似。我们认为这是由于内存不足，但我们想验证这一点。你们能协助这个过程吗？您将在下面找到 hs_err 文件中的相关信息。
谢谢！ 永
#
# 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
One of our dev servers keeps crashing every now and then and the reports look very similar. We're thinking it is due to lack of memory, but we want to verify this. Could you guys assist in this process? Below you'll find the relevant information from the hs_err file.
Thanks!
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
作为解决方法，您可以通过 "-XX:PermSize=256m -XX:MaxPermSize=256m" 增加 perm gen 的大小。它不能解决问题，但会延迟崩溃。
或者您可以尝试其他 gc 策略，例如并发 gc 。
As a work around, you can increase size of perm gen by "-XX:PermSize=256m -XX:MaxPermSize=256m" . It doesn't fix the problem, but it will delay the crash.
Or you can try other gc policy like concurrent gc .
内存不足不应导致 JVM 崩溃。如果确实如此，那就是 JVM 错误，而 JVM 错误的唯一真正修复方法就是升级。
我能想到的“你的错”的唯一可能性是：
你的代码或某些第三方库正在使用本机代码库来执行某些操作，并且该代码有错误，
您的 JVM 安装已被巧妙地损坏，或者
您有一个间歇性硬件故障机器。
如果您怀疑问题是内存不足，那么在启用 GC 日志记录的情况下运行应用程序可能会确认这一点。或者您可以调整堆大小和其他设置，并希望它们能够修复它。
在某些时候，您将不得不告诉您的客户您无法再为旧的（已报废的）JVM 上的安装提供支持。如果这是一个 JVM 错误（正如我们怀疑的那样），那么修复它的机会就很小……除非您/您的客户愿意向 Oracle 签署一张大支票以寻求支持。
Lack of memory should not cause JVM crashes. If it does, that is a JVM bug, and the only real fix for a JVM bug is to upgrade.
The only possibilities I can think of where this is "your fault" are:
your code or some third-party library is using native code libraries for something, and that code is buggy,
your JVM installation has been subtly corrupted, or
you've got an intermittent hardware fault on that machine.
If you suspect that the problem is lack of memory, then running the application with GC logging enabled may confirm this. Or you could just tweak the heap sizes and other settings and hope that they fix it.
At some point you are going to have to tell your customers that you can no longer provide support for installations on old (end-of-life'd) JVMs. If this is a JVM bug (as we suspect) then there is little chance of getting a fix for it ... unless you / your customers are willing to sign a BIG cheque to Oracle for support.