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

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

Current thread (0x0d242800):  JavaThread "CompilerThread1" daemon [_thread_in_native, id=26125, stack(0x0d0bc000,0x0d13d000)]

Stack: [0x0d0bc000,0x0d13d000],  sp=0x0d139ef0,  free space=503k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x708370]
V  [libjvm.so+0x2e8aaf]
V  [libjvm.so+0x153a1c]
V  [libjvm.so+0x153f46]
V  [libjvm.so+0x627879]
V  [libjvm.so+0x32fbcd]
V  [libjvm.so+0x53b3a6]
V  [libjvm.so+0x2af588]
V  [libjvm.so+0x2ac547]
V  [libjvm.so+0x239d6f]
V  [libjvm.so+0x2b573e]
V  [libjvm.so+0x2b4fb1]
V  [libjvm.so+0x6ccdd6]
V  [libjvm.so+0x6c604f]
V  [libjvm.so+0x5c6a6e]
C  [libpthread.so.0+0x5832]


Current CompileTask:
C2:5505  !   com.mysql.jdbc.ConnectionImpl.initializePropsFromServer()V (795 bytes)


Other Threads:
  0x113d6c00 VMThread [stack: 0x0d63f000,0x0d6c0000] [id=26119]
  0x0c8ae000 WatcherThread [stack: 0x0b646000,0x0b6c7000] [id=26202]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 par new generation   total 1887488K, used 883087K [0x11ef0000, 0x91ef0000, 0x91ef0000)
  eden space 1677824K,  45% used [0x11ef0000, 0x40dd8b38, 0x78570000)
  from space 209664K,  54% used [0x85230000, 0x8c1ab270, 0x91ef0000)
  to   space 209664K,   0% used [0x78570000, 0x78570000, 0x85230000)
 concurrent mark-sweep generation total 1538048K, used 558183K [0x91ef0000, 0xefcf0000, 0xefcf0000)
 concurrent-mark-sweep perm gen total 65536K, used 57375K [0xefcf0000, 0xf3cf0000, 0xf3cf0000)

从内存使用上来看  要申请 911864 bytes内存应该不是问题的啊？这种情况为什么会内存溢出呢？

日志我没有贴完太长了不知道够不够用。

你多半碰上HotSpot VM里动态编译器的bug了。请升级到JDK6u29或更高版本再试。

换JDK导致项目出异常不能启动   我暂时没有换JDK  这个是51期间爆的新错误跟之前编译导致的不一样。很诡异。

#
# A fatal error has been detected by the Java Runtime Environment:
#
# java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space?
#
#  Internal Error (allocation.cpp:166), pid=2827, tid=226290576
#  Error: ChunkPool::allocate
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) Server VM (19.1-b02 mixed mode linux-x86 )
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

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

Current thread (0x083be800):  VMThread [stack: 0x0d74e000,0x0d7cf000] [id=2839]

Stack: [0x0d74e000,0x0d7cf000],  sp=0x0d7cdd30,  free space=511k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x708370]
V  [libjvm.so+0x2e8aaf]
V  [libjvm.so+0x154168]
V  [libjvm.so+0x153f46]
V  [libjvm.so+0x627879]
V  [libjvm.so+0x70418d]
V  [libjvm.so+0x70011f]
V  [libjvm.so+0x193199]
V  [libjvm.so+0x192d64]
V  [libjvm.so+0x193627]
V  [libjvm.so+0x7180e6]
V  [libjvm.so+0x717593]
V  [libjvm.so+0x717800]
V  [libjvm.so+0x7172f0]
V  [libjvm.so+0x5c6a6e]
C  [libpthread.so.0+0x5832]

VM_Operation (0x0a44de40): BulkRevokeBias, mode: safepoint, requested by thread 0x0ce43400




Other Threads:
=>0x083be800 VMThread [stack: 0x0d74e000,0x0d7cf000] [id=2839]
  0x0c37f400 WatcherThread [stack: 0x09c3f000,0x09cc0000] [id=2924]

VM state:at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x081e3b28] Threads_lock - owner thread: 0x083be800

Heap
 par new generation   total 1887488K, used 802879K [0x11df0000, 0x91df0000, 0x91df0000)
  eden space 1677824K,  47% used [0x11df0000, 0x42dffd58, 0x78470000)
  from space 209664K,   0% used [0x85130000, 0x85130000, 0x91df0000)
  to   space 209664K,   0% used [0x78470000, 0x78470000, 0x85130000)
 concurrent mark-sweep generation total 1538048K, used 263673K [0x91df0000, 0xefbf0000, 0xefbf0000)
 concurrent-mark-sweep perm gen total 65536K, used 52959K [0xefbf0000, 0xf3bf0000, 0xf3bf0000)

请把前后几个crash日志的末尾部分发出来，类似这段：

/proc/meminfo:
MemTotal:      7680000 kB
MemFree:        164616 kB
Buffers:        503188 kB
Cached:        4350088 kB
SwapCached:          0 kB
Active:        2577652 kB
Inactive:      4552332 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:      7680000 kB
LowFree:        164616 kB
SwapTotal:     2096472 kB
SwapFree:      2096384 kB
Dirty:           81276 kB
Writeback:           0 kB
AnonPages:     2276540 kB
Mapped:          35432 kB
Slab:           200728 kB
PageTables:       9384 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   5936472 kB
Committed_AS:  4905252 kB
VmallocTotal: 34359738367 kB
VmallocUsed:      1220 kB
VmallocChunk: 34359737147 kB


CPU:total 4 (4 cores per cpu, 2 threads per core) family 6 model 26 stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, ht

Memory: 4k page, physical 7680000k(164616k free), swap 2096472k(2096384k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (19.0-b09) for linux-amd64 JRE (1.6.0_23-b05), built on Nov 12 2010 14:12:21 by "java_re" with gcc 3.2.2 (SuSE Linux)

time: Thu Aug 18 22:09:27 2011
elapsed time: 134 seconds

主要关注点是Memory: 4k page, physical 7680000k(164616k free), swap 2096472k(2096384k free)这行。多半swap已经是完全没free或几乎没free了。

你用的是32位系统和32位JVM，这种crash法很可能是地址空间耗光了或者虚拟内存系统整体耗光了。

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

OS:CentOS release 5.5 (Final)

uname:Linux 2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010 x86_64
libc:glibc 2.5 NPTL 2.5 
rlimit: STACK 10240k, CORE 0k, NPROC 65535, NOFILE 65535, AS infinity
load average:0.01 0.00 0.00

/proc/meminfo:
MemTotal:     16432980 kB
MemFree:      10056504 kB
Buffers:        321260 kB
Cached:        3137808 kB
SwapCached:          0 kB
Active:        4913832 kB
Inactive:      1066840 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:     16432980 kB
LowFree:      10056504 kB
SwapTotal:    18481144 kB
SwapFree:     18481144 kB
Dirty:             380 kB
Writeback:           0 kB
AnonPages:     2521384 kB
Mapped:          22764 kB
Slab:           341536 kB
PageTables:       7964 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:  26697632 kB
Committed_AS:  4360888 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    272568 kB
VmallocChunk: 34359465727 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB


CPU:total 8 (4 cores per cpu, 1 threads per core) family 6 model 44 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt

Memory: 4k page, physical 16432980k(10056504k free), swap 18481144k(18481144k free)

vm_info: Java HotSpot(TM) Server VM (19.1-b02) for linux-x86 JRE (1.6.0_24-b07), built on Feb  2 2011 16:51:52 by "java_re" with gcc 3.2.1-7a (J2SE release)

time: Tue May  1 20:30:02 2012
elapsed time: 177509 seconds

原来是在64位系统上用了32位JVM。可惜crash log里没有地方记录该进程自己消耗的内存的统计数据，得自己写脚本分析crash log里带的/proc/<pid>/maps的内容，麻烦。

如果你只想尽快缓解症状，懒得细究到底是怎么回事的话，请升级到JDK6 update 32的64位版。问题多半就消失了（如果原本真的只是32位地址空间耗光了的话），或者延缓较长时间才出现（如果原本实际上有内存泄漏的话）。

如果是32bit的JVM, 堆内存分配的太大了啦. 新生代1.8G + Old 1.5G? Linux 下 32bit 的程序最大可以用内存是3G.... 你这样分配不合理呀. 如果你要坚持32bit JVM, 请把堆内存尽量改成小于 2G. 或者升级到64bit的JVM