JDK18下SIGSEGV错误排查：如何调试Core Dump？

一、调试/var/crash下的Core Dump #

• 先修正core文件权限，避免gdb读取受限：

  sudo chmod 644 /var/crash/core.*
  

• 关联JDK18的java可执行文件与core文件启动gdb：

  gdb /path/to/jdk18/bin/java /var/crash/core.95484
  

• 进入gdb后执行thread apply all bt，打印所有线程调用栈，定位触发SIGSEGV的线程，重点查看AbstractMap.hashCode()的调用链路中是否存在自定义Map实现或第三方依赖类
• 若栈信息存在类名混淆，导入项目符号表或依赖jar包的调试信息，辅助定位具体代码

二、排查AbstractMap.hashCode()相关异常 #

• 检查项目中是否存在自定义Map子类重写hashCode()时实现不当，比如并发场景下遍历entrySet时修改Map（AbstractMap的hashCode()依赖entrySet遍历，并发修改可能触发内存访问错误）
• 排查核心类替换情况：用jdeps -s your-app.jar分析依赖，确认是否有第三方jar包包含java.util下的类，与JDK18核心库冲突
• 添加JVM参数-XX:+PrintClassHistogram，崩溃前打印类实例分布，排查是否存在Map实例异常堆积或内存泄漏

三、验证JDK18补丁版本 #

• 确认使用的是JDK18最新补丁版本（如18.0.2.x），部分SIGSEGV问题仅在小版本补丁中修复，而非初始的18.0.0版本
• 临时切换至JDK17或JDK21测试，若问题不复现，说明是JDK18特定bug，可排查OpenJDK已知issue，寻找临时规避方案

四、依赖冲突排查实操 #

• Maven项目执行mvn dependency:tree、Gradle项目执行gradle dependencies导出依赖树，搜索重复或老旧的Map相关依赖（如guava、commons-collections），尝试升级至兼容JDK18的版本
• 启动时添加-verbose:class参数，打印类加载日志，确认java.util.AbstractMap是否从JDK核心库加载，未被第三方类替换

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