Java虚拟机崩溃

(1) 最近刚上线的一个web application时不时的崩溃了, 唯一的日志就是那个hs_err_pidxxx.log

(2) 刚看到这个日志的时候很自然会以为是内存不够
Heap
 def new generation   total 52480K, used 46152K [0x02840000, 0x06130000, 0x09750000)
  eden space 46656K,  98% used [0x02840000, 0x0552d828, 0x055d0000)
  from space 5824K,   2% used [0x05b80000, 0x05ba4b30, 0x06130000)
  to   space 5824K,  12% used [0x055d0000, 0x0568b198, 0x05b80000)
 tenured generation   total 466048K, used 103634K [0x09750000, 0x25e70000, 0x41040000)
   the space 466048K,  22% used [0x09750000, 0x0fc84b58, 0x0fc84c00, 0x25e70000)
 compacting perm gen  total 23808K, used 23691K [0x41040000, 0x42780000, 0x45040000)
   the space 23808K,  99% used [0x41040000, 0x42762f10, 0x42763000, 0x42780000)
No shared spaces configured.

看到堆的perm gen 持久代和eden space新生代用得很尽, 使用
-XX:PermSize=64m -XX:MaxPermSize=128m-XX:NewRatio:1 -Xmx=..  -Xms=..
内存肯定会是分配够了.

不幸的是又crash and burn, 又一个日志, 内存使用率不高.

烦躁了, 好好想了一下, 一般情况下虚拟机不会那么脆弱的, 即使Stack或者Heap不够用的时候, 也会是抛异常的方式提示, StackOverFlowException或者OutOfMemoryError, 提示Perm gen不够用的异常等等

使用JDK下的jconsole.exe查看tomcat运行状态,即使并发大的时候内存之类的还是充裕的.
难道我的代码能让虚拟机直接挂, System.exit()? 再怎么错应该都是抛异常的.只好回到日志.


#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6da9b1a9, pid=3024, tid=348
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_06-b05 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x21b1a9]
#
Stack: [0x454e0000,0x45520000),  sp=0x4551f04c,  free space=252k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0x21b1a9]


# V这个表明是VM code字节码有问题,再继续跟下去.

Current CompileTask:
opto:865  !   xxxClass.xxxMethod(Ljava/lang/String;I)I (1526 bytes)

JVM当前是在编译?GOOGLE了一下 "Current CompileTask", 终于在老家SUN找到了点文档.

http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/gbyzo.html

===========================================================================

4.2.1 Crash in HotSpot Compiler Thread or Compiled Code

If the fatal error log indicates that the crash occurred in a compiler thread, then it is possible (but not always the case) that you have encountered a compiler bug. Similarly, if the crash is in compiled code then it is possible that the compiler has generated incorrect code.

In the case of the HotSpot Client VM (-client option), the compiler thread appears in the error log as CompilerThread0. With the HotSpot Server VM there are multiple compiler threads and these appear in the error log file as CompilerThread0, CompilerThread1, and AdapterThread.

Below is a fragment of an error log for a compiler bug that was encountered and fixed during the development of J2SE 5.0. In the log file we see that the HotSpot Server VM is used and the crash occurred in CompilerThread1. In addition, the log file shows that the Current CompileTask was the compilation of the java.lang.Thread.setPriority method.

# An unexpected error has been detected by HotSpot Virtual Machine:
#
:
# Java VM: Java HotSpot(TM) Server VM (1.5-internal-debug mixed mode)
:
---------------  T H R E A D  ---------------

Current thread (0x001e9350): JavaThread "CompilerThread1" daemon [_thread_in_vm, id=20]

Stack: [0xb2500000,0xb2580000),  sp=0xb257e500,  free space=505k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xc3b13c]
:

Current CompileTask:
opto: 11      java.lang.Thread.setPriority(I)V (53 bytes)

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x00229930 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=21]
=>0x001e9350 JavaThread "CompilerThread1" daemon [_thread_in_vm, id=20]
 :

In this case there are two potential workarounds:

• The brute force approach: change the configuration so that the application is run with the -client option to specify the HotSpot Client VM.

• Assume that the bug only occurs during the compilation of the setPriority method and exclude this method from compilation.

The first approach (to use the -client option) might be trivial to configure in some environments. In others, it might be more difficult if the configuration is complex or if the command line to configure the VM is not readily accessible. In general, switching from the HotSpot Server VM to the HotSpot Client VM also reduces the peak performance of an application. Depending on the environment, this might be acceptable until the actual issue is diagnosed and fixed.

The second approach (exclude the method from compilation) requires creating the file .hotspot_compiler in the working directory of the application. Below is an example of this file:

exclude	java/lang/Thread	setPriority

In general the format of this file is exclude CLASS METHOD, where CLASS is the class (fully qualified with the package name) and METHOD is the name of the method. Constructor methods are specified as <init> and static initializers are specified as <clinit>.

---

Note - The .hotspot_compiler file is an unsupported interface. It is documented here solely for the purposes of troubleshooting and finding a temporary workaround.

---

Once the application is restarted, the compiler will not attempt to compile any of the methods listed as excluded in the .hotspot_compiler file. In some cases this can provide temporary relief until the root cause of the crash is diagnosed and the bug is fixed.

In order to verify that the HotSpot VM correctly located and processed the .hotspot_compiler file that is shown in the example above, look for the following log information at runtime. Note that the file name separator is a dot, not a slash.

### Excluding compile:	java.lang.Thread::setPriority
======================================================================

解决方案
要么更新JRE版本, 要么别用server/jvm.dll, 把tomcat修改了下默认使用client/jvm.dll, 到现在似乎暂时还没出事,
希望解决了,祈祷...

SUN老家还是有很都好东西的,希望它没那么快倒了:o