介绍一款非常好用的jvm crash分析工具，当jvm挂掉时，会产生hs_err_pid.log。里面记录了jvm当时的运行状态以及错误信息，但是内容量比较庞大，不好分析。所以我们要借助工具来帮我们。
CrashAnalysis
这是一款诊断工具。是某APM项目组成员编写，里面把常见的问题分类并且给出解决方案或者方向，帮助我们定位问题。
下面是github地址，大家喜欢的话可以点个星。
https://github.com/xpbob/CrashAnalysis
工具使用方法
运行方式
通过执行jar命令，把log作为参数输入
java -jar CrashAnalysis-1.0-SNAPSHOT.jar ${hs_err_pid.log}
项目里默认带了一个编译好的jar包，如果jdk版本不适合，可以自己下载项目重新编译一版。
借助分析
诊断信息栏目
运行完成后，会有诊断信息的tab页，里面会告诉我们分析结果。
例如
这是一个解释器的问题，就是jvm把字节码转化成机器码出错了。
引起这种情况的原因有很多，一般都是jdk的bug
可以更换不同的jvm模式
例如-XInt,纯解释模式
在运行过程信息中有编译情况，可以查看具体编译到谁出错了
可以通过排除编译这些类来试试
这事分析的结果，指明了问题的原因是字节码转化机器码执行出错。而且给了建议，更改jvm模式，jdk模式是混合的，可以选择纯解释或者纯编译的模式来尝试运行。
可能的问题点
这个tab里列出的是jvm挂掉的原因，这里出现的内容主要是对log的解析，把当时jvm自己认为出错的点列举出来。我自己运行的结果是
问题模块：
C 0x0000000764928700
异常模块：
SIGSEGV (0xb) at pc=0x0000000764928700, pid=2788, tid=47906392385280
是一个c的模块的问题，后面跟的是地址，一般这种表述jvm解释出来的机器码。这里可以验证上面的分析。
线程信息模块
这个模块展示了当时运行的线程栈和正在运行的线程是什么。这里展示的就是线程信息，我这里不展示了。因为这个需要根据业务来匹配分析，通用性不大。
运行过程信息
这个模块的量特别大，也是特别要关注的地方。这里会列出jvm代码运行的错误（如果有的话），我们可以根据这里列出的异常来找到openjdk的源码，然后对应执行的内容，看看是否有参数可以规避。
这个模块还会列出编译事件，如果是jit带来的问题，他会把当时在编译哪些类列出来，在解释模式能解决问题的时候，可以选择禁用编译这里列举的类，或者也是一种解决思路。
系统信息
暂时只在这个模块看到内存情况，主要是用来分析内存使用问题的。这个具体情况具体分析，例如物理内存不够的时候，jvm申请不到内存，也会crash。
总结
虽然工具给了诊断内容和可靠的信息，但是这个只能辅助我们去找原因和解决方案，例如是jvm的问题，我们还是要借助线程信息以及运行过程信息来确认jvm的代码是否真的有问题。
