本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
很多 java 程序员可能并没有遇到过 hs_err_pid.log 崩溃文件。并不是说他们 java 代码写的有多好，而且可能写的少。最近有网友在微信后台留言，java 程序崩溃了，生成了一个 hs_err_pid.log 文件，我该怎么办？怎么处理？于是就有了本文，带领大家一起分析 hs_err_pid.log 文件！
如果你的程序产生了 hs_err_pid.log 文件，那将是非常致命的错误。那不是你的 java 程序崩溃了，而是 JVM 虚拟机崩溃了，比你的 java 程序严重的多了，它能影响多个正在运行的 Java 进程。
当JVM发生致命错误导致崩溃时，会生成一个hs_err_pid_xxx.log这样的文件，该文件包含了导致 JVM crash 的重要信息，我们可以通过分析该文件定位到导致 JVM Crash 的原因，从而修复保证系统稳定。
默认情况下，该文件是生成在工作目录下的，当然也可以通过 JVM 参数指定生成路径：
java -XX:ErrorFile=/var/log/hs_err_pid<pid>.log
这个文件主要包含如下内容：
- 日志头文件
- 导致 crash 的线程信息
- 所有线程信息
- 安全点和锁信息
- 堆信息
- 本地代码缓存
- 编译事件
- gc 相关记录
- jvm 内存映射
- jvm 启动参数
- 服务器信息
分析的第一步是查看文件头：
# SIGSEGV (0xb) at pc=0x03568cf4, pid=16819, tid=3073346448
一个非预期的错误被JRE检测到，其中：
- SIGSEGV是信号名称
- 0xb是信号码
- pc=0x03568cf4指的是程序计数器的值
- pid=16819是进程号
- tid=3073346448是线程号
如果你对JVM有了解，应该不会对这些东西陌生。
接下来是JRE和JVM的版本信息：
# JRE version: 6.0_32-b05 # Java VM: Java HotSpot(TM) Server VM (20.7-b02 mixed mode linux-x86 )
mixed 是一种模式，然后是问题帧的信息：
# Problematic frame: # C [libgtk-x11-2.0.so.0+0x19fcf4] __float128+0x19fcf4
C：帧类型为本地帧，帧的类型包括：
- C：本地C帧
- j：解释的Java帧
- V：虚拟机帧
- v：虚拟机生成的存根栈帧
- J：其他帧类型，包括编译后的Java帧
libgtk-x11-2.0.so.0+0x19fcf4：和程序计数器（pc）表达的含义一样，但是用的是本地so库+偏移量的方式。
再接着就是线程的信息了：
Current thread (0x09f30c00): JavaThread "main" [_thread_in_native, id=16822, stack(0xb72a8000,0xb72f9000)]
Current thread 是当前线程。
- 0x09f30c00：指针
-
JavaThread：线程类型，可能的类型包括：
- JavaThread
- VMThread
- CompilerThread
- GCTaskThread
- WatcherThread
- ConcurrentMarkSweepThread
-
main：名字
- _thread_in_native：线程当前状态，状态枚举包括：
- _thread_uninitialized：线程还没有创建，它只在内存原因崩溃的时候才出现
- _thread_new：线程已经被创建，但是还没有启动
- _thread_in_native：线程正在执行本地代码，一般这种情况很可能是本地代码有问题
- _thread_in_vm：线程正在执行虚拟机代码
- _thread_in_Java：线程正在执行解释或者编译后的Java代码
- _thread_blocked：线程处于阻塞状态
- …_trans：以_trans结尾，线程正处于要切换到其它状态的中间状态
- id=16822：线程ID
- 0xb72a8000,0xb72f9000：栈区间
再接着是信号信息：
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00000010
这部分是导致虚拟机终止的非预期的信号信息，含义前面已经大致提到过了。其中si_errno和si_code是Linux下用来鉴别异常的，Windows下是一个ExceptionCode。
EAX=0x00000000, EBX=0x0375dd84, ECX=0x00000000, EDX=0x00000000 ESP=0xb72f0fa0, EBP=0xb72f0fb8, ESI=0x00000000, EDI=0x0a6c1800 EIP=0x03568cf4, EFLAGS=0x00010246, CR2=0x00000010
接着是寄存器上下文内容：
Top of Stack: (sp=0xb72f0fa0) 0xb72f0fa0: 00000000 00402250 0040217f 0375dd84 0xb72f0fb0: 00000000 0a6c1800 b72f0fe8 0356c2c0 0xb72f0fc0: 00000000 0a6c1800 b72f0fe8 003b3e77 0xb72f0fd0: 003e6c8b 0a1a70d0 0a193358 0375dd84 0xb72f0fe0: 0a276418 0a276418 b72f1048 03536c56 0xb72f0ff0: 0acad000 0b3ca978 0000000c 00dd0674 0xb72f1000: 00000003 0a2c7d50 b72f1038 0000330c 0xb72f1010: ffffffff ffffffff 00000001 00000001 Instructions: (pc=0x03568cf4) 0x03568cd4: 89 14 24 89 75 f8 89 d6 89 7d fc 89 c7 e8 7e 1b 0x03568ce4: ea ff 89 34 24 89 87 d4 02 00 00 e8 30 00 ea ff 0x03568cf4: 8b 40 10 89 3c 24 c7 44 24 08 00 00 00 00 89 87 0x03568d04: d0 02 00 00 8b 83 88 24 00 00 89 44 24 04 e8 dd
栈顶程序计数器旁的操作码，它们可以被反汇编成系统崩溃前执行的指令。
Register to memory mapping: EAX=0x00000000 is an unknown value EBX=0x0375dd84: <offset 0x394d84> in /usr/lib/libgtk-x11-2.0.so.0 at 0x033c9000 ECX=0x00000000 is an unknown value EDX=0x00000000 is an unknown value ESP=0xb72f0fa0 is pointing into the stack for thread: 0x09f30c00 EBP=0xb72f0fb8 is pointing into the stack for thread: 0x09f30c00 ESI=0x00000000 is an unknown value EDI=0x0a6c1800 is an unknown value
寄存器和内存映射信息。
线程栈。包含了地址、栈顶、栈计数器和线程尚未使用的栈信息，由于栈可能非常长，打印的长度有限制，但是至少本地栈和Java栈都打印出来了（很多时候本地栈打印不出来，但是Java栈一般都能打印出来）。从中可以看到，Eclipse的虚拟机崩溃了。
ava Threads: ( => current thread ) 0x0b4c1000 JavaThread "Worker-247" [_thread_blocked, id=25417, stack(0x741bc000,0x7420d000)] 0x0a300c00 JavaThread "Worker-246" [_thread_blocked, id=25235, stack(0x7d30c000,0x7d35d000)] ... ...
线程信息。一目了然。
VM state:not at safepoint (normal execution)
虚拟机状态。包括：
- not at a safepoint：正常运行状态；
- at safepoint：所有线程都因为虚拟机等待状态而阻塞，等待一个虚拟机操作完成；
- synchronizing：一个特殊的虚拟机操作，要求虚拟机内的其它线程保持等待状态。
VM Mutex/Monitor currently owned by a thread: None
虚拟机的Mutex和Monitor目前没有被线程持有。Mutex是虚拟机内部的锁，而Monitor则关联到了Java对象。
堆信息。新生代、老生代、永久代。对JVM有了解的人应该都清楚。
Code Cache [0xb4262000, 0xb5ac2000, 0xb7262000) total_blobs=5795 nmethods=5534 adapters=209 free_code_cache=25103616 largest_free_block=38336
代码缓存（Code Cache）。这是一块用于编译和保存本地代码的内存，注意是本地代码，它和PermGen（永久代）是不一样的，永久带是用来存放Java类定义的。
Dynamic libraries: 00101000-00122000 r-xp 00000000 08:01 3483560 /usr/lib/libjpeg.so.62.0.0 00122000-00123000 rwxp 00020000 08:01 3483560 /usr/lib/libjpeg.so.62.0.0 00125000-00130000 r-xp 00000000 08:01 9093202 /lib/libgcc_s-4.1.2-20080825.so.1 00130000-00131000 rwxp 0000a000 08:01 9093202 /lib/libgcc_s-4.1.2-20080825.so.1 ... ...
内存映射。这些信息是虚拟机崩溃时的虚拟内存列表区域。在定位崩溃原因的时候，它可以告诉你哪些类库正在被使用，位置在哪里，还有堆栈和守护页信息。就以列表中第一条为例说明：
- 00101000-00122000：内存区域
- r-xp：权限，r/w/x/p/s分别表示读/写/执行/私有/共享
- 00000000：文件内的偏移量
- 08:01：文件位置的majorID和minorID
- 3483560：索引节点号
- /usr/lib/libjpeg.so.62.0.0：文件位置
每一个lib都有两块虚拟内存区域——代码和数据，它们的权限不同，代码区域是r-xp；数据区域是rwxp。守护页（guard page）由权限为–xp和rwxp的一对组成。
VM Arguments: jvm_args: -Dosgi.requiredJavaVersion=1.5 -XX:MaxPermSize=256m -Xms40m -Xmx512m -Dorg.eclipse.swt.browser.XULRunnerPath='' java_command: /.../eclipse/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar -os linux -ws gtk -arch x86 -showsplash -launcher /.../eclipse/eclipse -name Eclipse ... Launcher Type: SUN_STANDARD Environment Variables: PATH=... DISPLAY=:0.0
虚拟机参数和环境变量。
Signal Handlers: SIGSEGV: [libjvm.so+0x726440], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGBUS: [libjvm.so+0x726440], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 ... ...
信号句柄。对于Linux下的信号机制，参阅wiki百科，链接。
是不是感觉分析起来非常的麻烦，不用怕，扫描下方二维码，关注“业余草”微信公众号，我们一起学习！
后面会介绍一款工具 CrashAnalysis，它会智能的自动的给出我们分析结果，展示分析报告，而且是中文的报告哦。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » jvm crash(崩溃)文件 hs_err_pid.log 分析教程