转载

原荐 jvm crash分析工具

介绍一款非常好用的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的代码是否真的有问题。

原文 https://my.oschina.net/xpbob/blog/2208006

正文到此结束

所属分类： Java 编程技术

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。