前两天运行自己的项目的时候发生了jvm异常，并在项目目录下生成了一个hs_err_pid8720.log文件。
这是jvm发生异常时产生异常日志文件的默认格式：hs_err_pid**.log文件。
文件内部的信息肯定能帮助我们发现一些端倪，但是由于我水平有限一点也看不懂就在网上查找如何看jvm的异常日志。就发现两个大佬的博客写的都不错，但是他俩写的都相对不太全面。(比我肯定是强太多)就把他两的博客都拿过来以便帮助我来学习，如果能帮到正在看的观众老爷那自然是极好的(哈哈)。在文章末尾我会把二位大佬的链接贴上以示尊重。
开始(说一下后面几乎没有我的东西)：
当jvm出现致命错误时，会生成一个错误文件 hs_err_pid.log，其中包括了导致jvm crash的重要信息，可以通过分析该文件定位到导致crash的根源，从而改善以保证系统稳定。当出现crash时，该文件默认会生成到工作目录下，然而可以通过jvm参数指定生成路径(JDK6中引入)：
-XX:ErrorFile=./hs_err_pid.log
1该文件包含如下几类关键信息：
日志头文件
导致crash的线程信息
所有线程信息
安全点和锁信息
堆信息
本地代码缓存
编译事件
gc相关记录
jvm内存映射
jvm启动参数
下面用一个crash demo文件逐步解读这些信息，以便大家以后碰到crash时方便分析。
那么：
一. 如何得到这个日志文件
如果有一个严重的错误引起Java进程非正常退出，我们叫Crash，这时候会产生一个日志文件。缺省情况下，这个
文件会产生在工作目录下。但是，可以在Java启动参数通过下面的设置，来改变这个文件的位置和命名规则。例如：
java -XX:ErrorFile=/var/log/java/java_error_%p.log
就将这个错误文件放在/var/log/java下，并且以java_error_pid.log的形式出现。(插一句：我的log文件就在项目目录下)
二.产生错误的原因
造成严重错误的原因有多种可能性。Java虚拟机自身的Bug是原因之一，但是这种可能不是很大。在绝大多数情况下，
是由于系统的库文件、API或第三方的库文件造成的；系统资源的短缺也有可能造成这种严重的错误。在发生了Crash
之后，如果无法定位根本原因，也应该迅速找到Work Around的方法。
对日志文件头的分析：
日志头文件包含概要信息，简述了导致crash的原因。而导致crash的原因很多，常见的原因有jvm自身的bug，应用程序错误，jvm参数配置不当，服务器资源不足，jni调用错误等。
现在参考下如下描述：
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fb8b18fdc6c, pid=191899, tid=140417770411776
#
# JRE version: Java(TM) SE Runtime Environment (7.0_55-b13) (build 1.7.0_55-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.55-b03 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/List;)Ljava/util/List;
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#这里一个重要信息是“SIGSEGV(0xb)”表示jvm crash时正在执行jni代码，而不是在执行java或者jvm的代码，如果没有在应用程序里手动调用jni代码，那么很可能是JIT动态编译时导致的该错误。其中SIGSEGV是信号名称，0xb是信号码，pc=0x00007fb8b18fdc6c指的是程序计数器的值，pid=191899是进程号，tid=140417770411776是线程号。
PS：除了“SIGSEGV(0xb)”以外，常见的描述还有“EXCEPTION_ACCESS_VIOLATION”，该描述表示jvm crash时正在执行jvm自身的代码，这往往是因为jvm的bug导致的crash；另一种常见的描述是“EXCEPTION_STACK_OVERFLOW”，该描述表示这是个栈溢出导致的错误，这往往是应用程序中存在深层递归导致的。(加粗的是知识点)
还有一个重要信息是：
# Problematic frame:
# J org.apache.http.impl.cookie.BestMatchSpec.formatCookies(Ljava/util/List;)Ljava/util/List;
这表示出现crash时jvm正在执行的代码，这里的“J”表示正在执行java代码，后面的表示执行的方法栈。除了“J”外，还有可能是“C”、“j”、“V”、“v”，它们分别表示：
C: Native C frame
j: Interpreted Java frame
V: VMframe
v: VMgenerated stub frame
J: Other frame types, including compiled Java frames加上前面对SIGSEGV(0xb)”的分析，现在可以断定是JIT动态编译导致的该错误。
不写了，两个我糅合不到一块，先发了。不过我还会回来的。
