java – JVM(64位1.5.0._22)在GCTaskThread崩溃

前端之家收集整理的这篇文章主要介绍了java – 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
最佳答案
缺少内存不应导致JVM崩溃.如果是这样,那就是JVM错误,并且JVM错误的唯一真正修复就是升级.

我能想到的唯一可能性是“你的错”:

>您的代码或某些第三方库正在使用本机代码库,而且该代码有问题,
>您的JVM安装已被巧妙地破坏,或
>你在那台机器上发生间歇性硬件故障.

如果您怀疑问题是内存不足,那么启用GC日志记录运行应用程序可能会确认这一点.或者你可以调整堆大小和其他设置,并希望他们修复它.

在某些时候,您将不得不告诉您的客户,您无法再为旧(生命终结)JVM上的安装提供支持.如果这是一个JVM错误(我们怀疑),那么几乎没有机会得到它…除非你/你的客户愿意签署一个BIG支票给Oracle支持.

原文链接:/jvm/437889.html

猜你在找的JVM相关文章