CentOS 7执行java -version出现Segmentation Fault (core dumped)求助

这种段错误的情况我之前排查过几次，给你几个逐步验证的方向，你可以按顺序试试：

• 先验证JDK安装包的完整性
  有时候下载的tar.gz包可能损坏，或者解压过程中出问题。直接运行JDK目录下的原生java命令，绕开软链接和环境变量：

  /usr/java/jdk1.8.0_151/bin/java -version
  

  如果这个命令也报段错误，那大概率是JDK包本身的问题。去Oracle官网重新下载对应版本，记得校验MD5或SHA256哈希值，确保包没损坏。

• 检查系统依赖库是否缺失
  Oracle JDK 1.8依赖一些系统底层库，比如glibc、libstdc++等。用ldd命令查看依赖情况：

  ldd /usr/java/jdk1.8.0_151/bin/java
  

  输出里如果有not found的项，说明缺少对应的库，用yum安装即可（比如yum install glibc-devel libstdc++-devel）。

• 排查环境变量冲突
  有时候全局配置文件（比如/etc/bashrc、用户家目录的.bashrc/.bash_profile）里的旧配置会和你设置的/etc/profile冲突。可以临时进入干净的环境测试：

  env -i bash
  export JAVA_HOME=/usr/java/jdk1.8.0_151
  export PATH=$JAVA_HOME/bin:$PATH
  export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
  java -version
  

  如果这次能正常输出版本，说明是环境变量有冲突，逐个检查其他配置文件里的Java相关配置，删掉重复或冲突的部分。

• 检查SELinux的限制
  很多系统默认开启SELinux，可能会阻止JDK的某些操作。先临时关闭SELinux测试：

  setenforce 0
  java -version
  

  如果恢复正常，说明是SELinux的问题。可以给JDK目录添加正确的上下文，不用永久关闭SELinux：

  chcon -R -t textrel_shlib_t /usr/java/jdk1.8.0_151/
  

• 分析核心转储文件定位问题
  如果系统允许生成core dump，用gdb分析能直接看到错误栈：

  1. 先设置允许生成core文件：

     ulimit -c unlimited
     

  2. 再次运行java -version触发错误，当前目录会生成core文件
  3. 用gdb分析：

     gdb /usr/java/jdk1.8.0_151/bin/java core
     

  输入bt命令查看调用栈，能定位到是JDK内部的哪个模块出问题，或者是哪个系统库导致的崩溃。

• 确认系统架构与JDK匹配
  检查你的系统是32位还是64位：

  uname -m
  

  再看JDK的架构：

  file /usr/java/jdk1.8.0_151/bin/java
  

  如果系统是x86_64但JDK是32位，就会出现兼容性问题，重新下载对应架构的JDK即可。

• 清理OpenJDK残留文件
  虽然用yum remove java*卸载了，但可能还有残留的库文件或配置干扰Oracle JDK。查找并清理这些残留：

  find /usr -name "*java*" | grep -v jdk1.8.0_151
  

  重点关注.so后缀的库文件，如果发现属于OpenJDK的残留，直接删除（注意备份，避免误删系统文件）。

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