JAVA应用Crash错误分析

  昨天晚上启动jboss之后，发现点击某个页面，总是crash掉；控制台信息如下：
----------------------------------------------------------------------------------------------------------------
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6dd1a7a1, pid=6044, tid=2744
#
# JRE version: 6.0_22-b04
# Java VM: Java HotSpot(TM) Server VM (17.1-b03 mixed mode windows-x86 )
# Problematic frame:
# V  [jvm.dll+0x1aa7a1]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
----------------------------------------------------------------------------------------------------------------

  后来同事将他的JOBSS给我，当时是OK了，同事说是JVM启动参数不一样，当时也没有深究;结果今天早上上来在什么都没有修改的情况下，居然又crash了;乘着这个加深学习了下JVM的一些参数配置知识。

(一)产生错误的原因
造成严重错误的原因有多种可能性。Java虚拟机自身的Bug是原因之一，但是这种可能性很小。在绝大多数情况下，是由于系统的库文件、API或第三方的库文件造成的；或者是系统资源的短缺也有可能造成这种严重的错误。

(二).对日志文件的分析
日志头中“EXCEPTION_ACCESS_VIOLATION ”标明了日志错误类型。一般还有另外一种常见的错误类型：EXCEPTION_STACK_OVERFLOW;
日志中另外一个有用的信息就是：
# Problematic frame:
# V  [jvm.dll+0x1aa7a1]
它说明Crash的时候，JVM正在从哪个库文件执行代码。除了“V”以外，还有可能是“C”、“j”、“v”、“J”。具体的表示意思如下：
FrameType Description：
C: Native C frame
j: Interpreted Java frame
V: VMframe
v: VMgenerated stub frame
J: Other frame types, including compiled Java frames

EXCEPTION_ACCESS_VIOLATION加上“ # Problematic frame: # V [jvm.dll+....”说明一般是内存回收引起的问题。对于内存回收的错误，一般采取改变回收的算法和参数的方法来绕过去。可改变内存回收的算法，或者优化JVM配置参数来解决。
所以在本次错误中，优化JBOSS中JVM的启动参数可以解决问题。但是为什么一模一样的配置，昨天晚上OK的，今天早上却失败了？具体的我现在也没有明确的答案，我猜测可能是在特定的条件下（比如说本机的系统资源，远程调用的系统稳定性，以及网络是否繁忙等都可能会产生影响）产生的。


(三).其他常见错误
1.java.lang.OutOfMemoryError: Java heap space
当设置JBOSS启动参数：
set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx128m

后台日志报错：

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'xxxAO' defined in resource loader resource [/xxx/biz/bean/biz-xx.xml]: Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'xxxServices' defined in resource loader resource [/xxx/biz/bean/biz-xxx.xml]: Invocation of init method failed; nested exception is java.lang.OutOfMemoryError: Java heap space

分析：
这里是指最大堆内存设置太小，可以通过设置JBOSS启动参数：–Xmx 增加堆内存即可；

2.java.lang.OutOfMemoryError: GC overhead limit exceeded
当设置JBOSS启动参数：
set JAVA_OPTS=%JAVA_OPTS% -Xms128m –Xmx256m
日志错误：

java.lang.OutOfMemoryError: GC overhead limit exceeded

分析：
意味着太多的时间花在了垃圾收集上面,SUN的建议是指定垃圾回收的算法，加上启动参数-XX:-UseGCOverheadLimit，从而限制JVM在抛出OutOfMemoryError之前限制其耗费在GC上的时间。
SUN的原文：
The parallel / concurrent collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.

3.另外一种常见错误：ava.lang.OutOfMemoryError: PermGen space
这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。
解决方法： 手动设置MaxPermSize大小



另外：
JBOSS启动参数说明
另外：
JBOSS启动参数说明
-Xms256m 初始的java内存堆大小 256M
-Xmx2048m 最大的java内存堆大小 2048M
-XX:PermSize=128m GC预留的内存，如果你的应用有大量的Class被动态载入或卸载，你应该不这个参数设大些
-XX:MaxPermSize=256m 最大的GC预留内存
-Dsun.rmi.dgc.client.gcInterval=3600000 RMI客户端GC发生周期的设定
-Dsun.rmi.dgc.server.gcInterval=3600000 RMI服务端GC发生周期的设定

参考资料：
http://blog.csdn.net/sfdev/archive/2008/01/24/2063928.aspx
http://developers.sun.com.cn/blog/yutoujava/entry/20070411#comments