CentOS下JVM 1.8因SIGABRT崩溃及Java应用Core Dump异常求助

嘿，我来帮你梳理下这两个问题，先从最容易混淆的点开始拆解：

先澄清：SIGABRT就是Signal 6 #

首先别慌，Linux系统里SIGABRT对应的就是Signal 6——这俩是同一个信号的不同叫法，所以Core Dump里的“signal 6终止”和你说的JVM因SIGABRT崩溃，本质上是一回事。你觉得不符，大概率是hs_err_pid文件的内容和Core Dump分析出来的信息对不上，咱们重点解决这个矛盾点。

JVM触发SIGABRT崩溃的常见原因 #

先给你列几个高频触发场景，方便你先做初步排查：

• 内存相关问题：不管是Java堆OOM，还是native内存溢出（比如JNI调用的第三方库内存泄漏、分配失败），都可能让JVM触发SIGABRT自我终止。如果你的应用开了-XX:+HeapDumpOnOutOfMemoryError，有时候OOM后JVM在生成堆转储的过程中也会崩。
• JNI代码bug：如果你的应用依赖JNI（比如自定义native代码、某些数据库驱动/中间件的底层实现），native层的断言失败（assert()触发）、空指针访问、内存越界这类错误，都会直接抛出SIGABRT。这时候hs_err_pid里会有Native Stack Trace部分，重点看这一块的调用栈。
• JVM自身bug：JVM 1.8的某些旧版本存在已知的崩溃bug，比如特定GC组合（比如ParallelGC+CMS）、类加载逻辑里的问题。你可以先查下自己的JVM版本（java -version），看看对应版本有没有官方记录的类似崩溃issue。
• 系统资源耗尽：比如进程打开文件数超限（ulimit -n看当前限制）、系统物理内存被榨干导致JVM无法分配内存，也可能触发SIGABRT。不过系统OOM Killer一般发SIGKILL（signal 9），这点可以区分开。

解决Core Dump与hs_err_pid内容不符的问题 #

这是你最困惑的点，给你列几个可能的原因和排查步骤：

• 文件对应关系搞混了：如果短时间内JVM崩了好几次，会生成多个hs_err_pid和Core Dump文件，你可能把不同崩溃实例的文件混在一起对比了。用ls -lt查看文件的修改时间，找时间戳完全接近的一对来分析。
• hs_err_pid生成不完整：JVM崩溃时如果磁盘空间满了、或者hs_err_pid所在目录没有写入权限，文件可能没写完就中断了。检查下磁盘空间（df -h）和目录权限（ls -l），看看文件末尾有没有完整的错误总结（比如Problematic frame字段）。
• Core Dump被截断或损坏：如果系统的Core Dump大小限制设得太小（ulimit -c查看，值为0就是关闭了Core Dump），或者磁盘空间不足，生成的Core Dump会不完整。先把Core Dump限制打开：ulimit -c unlimited，永久生效的话要改/etc/security/limits.conf文件。
• JVM参数影响了错误日志：比如你设置了-XX:ErrorFile指定了自定义的hs_err_pid路径，可能找错了文件；或者用了-XX:-CreateMinidumpOnCrash这类参数抑制了部分日志内容。检查下应用的启动参数里有没有相关配置。
• 手动分析Core Dump验证：用gdb加载Core Dump和JVM的可执行文件，直接看崩溃时的线程栈，和hs_err_pid对比：

  # 替换成你的JVM路径和Core Dump文件名
  gdb /usr/lib/jvm/java-1.8.0-openjdk/bin/java core.12345
  # 查看所有线程的调用栈
  (gdb) thread apply all bt
  

  这样能直接拿到最原始的崩溃现场，判断是hs_err_pid没记录全，还是其他问题。

下一步建议的排查动作 #

1. 先确认你对比的hs_err_pid和Core Dump是同一崩溃实例（时间戳匹配）；
2. 检查hs_err_pid的完整性，重点看Problematic frame、Native Stack Trace、Physical Memory这些字段；
3. 如果有JNI调用，优先排查native代码的逻辑，比如有没有内存泄漏、非法访问；
4. 把JVM升级到1.8的最新补丁版本，排除已知的JVM bug；
5. 确保系统Core Dump配置正确，磁盘空间充足。

内容的提问来源于stack exchange，提问作者wukong