java core dump分析实战
hs_err_pid简介
hs_err_pid<pid>.log是java程序发生core的时候产生的文件，里面有当时出错时jvm的执行情况。
排查方法
头文件解读可以查看问题
头文件包含了简单的信息阐述，里面就core掉的原因
#
# An unexpected error has been detected by Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x69ba3a96, pid=376, tid=1848
#
# Java VM: Java HotSpot(TM) Client VM (11.0-b16 mixed mode, sharing windows-x86)
# Problematic frame:
# C [nvoglnt.dll+0x6a3a96]
#
这里的问题是动态库的调用，这个库如果不是java自带的库，而是第三方的库，那么可以查看这个库是否和机型系统想匹配，如果不匹配换匹配的库就好，如果匹配，需要重新安装该库尝试。
#
# Out of Memory Error (os_linux_x86.cpp:718), pid=29229, tid=140505843455744
#
# JRE version: Java(TM) SE Runtime Environment (7.0_67-b01) (build 1.7.0_67-b01)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
这里直接指出了问题的原因是oom，后面还会有物理内存状态，可以用来印证这个错误。
头文件+栈信息
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x009fcf52, pid=4344, tid=5876
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_14-b03 mixed mode)
# Problematic frame:
# V [jvm.dll+0x9cf52]
#
头文件信息告诉我们是jvm.dll这个是jvm自己的库。此时就不能单纯的依靠这个信息来换库解决。
必须看栈信息，一般会有两个模块，一个是Native frames一个是Java frames。
Stack: [0x00030000,0x00070000), sp=0x0006f934, free space=254k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x9cf52]
C [NativeCode.dll+0x148b]
C [NativeCode.dll+0x1253]
j com.sy.test.TestNative.sayHello()V+0
j com.sy.test.TestNative.main([Ljava/lang/String;)V+22
v ~StubRoutines::call_stub
V [jvm.dll+0x875dd]
V [jvm.dll+0xdfd96]
V [jvm.dll+0x874ae]
V [jvm.dll+0x8e6f1]
C [javaw.exe+0x14c5]
C [javaw.exe+0x3151]
C [kernel32.dll+0x16fd7]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j com.sy.test.TestNative.sayHello()V+0
j com.sy.test.TestNative.main([Ljava/lang/String;)V+22
v ~StubRoutines::call_stub
上面的信息，是从java调用到c了，极大的可能是jni的形式，此时需要查看，后面的PATH,LD_LIBRARY_PATH,以及-Djava.library.path查看是否编写了JNI。
场景问题
80%的问题上面的方法都可以推断和解决，下面说说20%的情况
jit问题表征
# JRE version: Java(TM) SE Runtime Environment (8.0_25-b17) (build 1.8.0_25-b17)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C 0x0000000764928700
Stack: [0x00002b9213782000,0x00002b9213803000], sp=0x00002b92137fe6d0, free space=497k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0x0000000764928700
这种直接就是问题都是寄存器地址的，也没有栈信息的，基本问题在JIT
# Problematic frame:
# J org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/List;)Ljava/util/List;
上面这种造成core的是java代码引起的，是解释器的问题，基本问题在JIT
纯jvm代码
# JRE version: 6.0_45-b06
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.45-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# v ~StubRoutines::jshort_disjoint_arraycopy
Stack: [0x00007fecfc9dc000,0x00007fecfca1d000], sp=0x00007fecfca1b4b0, free space=253k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::jshort_disjoint_arraycopy
上图整体的信息都是jvm的代码，这种情况一般是jvm的bug，可以查jvm的bug列表并且更换jdk
引用案例出处
http://bbs.csdn.net/topics/390975171
http://blog.csdn.net/zct08/article/details/6333467
http://m635674608.iteye.com/blog/2257650
