CentOS Java服务故障排查方法

在CentOS上运行Java服务，最怕的就是服务突然挂掉或者响应速度极慢。此时不必急于重启，应先理清故障排查的步骤——从环境配置、进程状态、日志分析、资源监控到工具辅助，每个环节都有章可循。下面将这几个核心方向逐一展开说明。

1. 检查Java环境配置

Java服务能够正常运行，环境变量必须正确。执行echo $JAVA_HOME，如果输出为空或者路径不正确（例如未指向JDK安装目录），则需要修改/etc/profile或~/.bashrc。添加以下两行：

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk
# 根据实际JDK路径修改
export PATH=$JAVA_HOME/bin:$PATH

修改完成后执行source /etc/profile使配置生效。然后再运行java -version和javac -version，如果提示“command not found”，则需要重新安装JDK，例如yum install java-1.8.0-openjdk-devel。

2. 查看Java进程状态

服务未启动？或者启动后卡死？首先查看进程。执行ps -ef | grep java，关注PID、运行用户以及启动命令。如果进程存在但CPU占用极高（例如持续超过80%），很可能存在死循环或内存泄漏。此时使用top -H -p 可以更细致地查看每个线程的资源占用情况。

3. 分析日志文件

日志是故障定位的第一线索，不可跳过。首先找到日志文件位置——Spring Boot一般在application.properties中配置了logging.file.name，Tomcat的catalina.out位于$CATALINA_HOME/logs下。实时跟踪使用tail -f /path/to/logfile.log，一旦报错立刻可见。如需快速过滤错误，使用grep "ERROR"或grep -i "exception"，重点关注堆栈跟踪（Stack Trace），像NullPointerException、ClassNotFoundException这些异常的根源就在那几行中。

4. 排查端口冲突

启动时若报“Port already in use”，多半是端口被占用。使用netstat -tuln | grep <端口号>（例如8080）查出是哪个进程占用。如果不影响业务，直接kill -9 终止它；如果该进程有用，则修改Java应用的端口配置——Tomcat修改server.xml中的。

5. 监控系统资源

CPU、内存、磁盘任一资源耗尽，Java服务都会出现问题（如OOM、响应慢）。
- CPU：top查看整体情况，top -H -p 查看Java进程细节。
- 内存：free -h查看系统可用内存（关注available列），再使用jstat -gc 1000监控JVM堆的GC情况——如果频繁Full GC，基本可判定为内存泄漏。
- 磁盘：df -h检查分区空间，根分区低于10%时应清理旧日志。

6. 使用故障排查工具

仅靠肉眼观察不够，专业工具能挖掘更深层次的问题。
- 线程分析：jstack 生成线程堆栈，用grep "deadlock"查找死锁；或使用show-busy-java-threads.sh脚本快速定位CPU占用高的线程。
- 内存分析：jmap -dump:format=b,file=heap.hprof 导出堆转储文件，再使用Eclipse MAT打开，可直观看出哪个对象撑爆了内存。
- GC监控：jstat -gcutil 1000查看Eden、Survivor、Old各区域的使用率和GC耗时，判断GC是否频繁。

7. 检查配置文件

配置写错会导致服务无法启动或运行异常。逐项检查：
- 应用配置：Spring Boot的application.properties/application.yml，Tomcat的server.xml，确认端口、数据库连接、日志路径均正确。
- 启动脚本：start.sh或run.sh中的JAVA_HOME、CLASSPATH，启动命令如java -jar app.jar是否有拼写错误。

8. 解决常见问题

• ClassNotFoundException/NoClassDefFoundError：依赖未打包完整。检查Maven的pom.xml或启动脚本的-cp参数。
• OutOfMemoryError：要么调整堆内存参数（-Xms512m -Xmx1024m），要么修复内存泄漏（例如数据库连接未关闭、集合类无限增长）。
• 端口冲突：要么终止占用进程，要么修改端口。
• 权限问题：确保Java进程对日志目录、数据目录拥有读写权限，使用chown -R user:user /path/to/logs。

按照以上步骤操作，大多数CentOS上Java服务的故障都能找到根源。实际排查时不宜死板，应结合具体错误信息灵活调整——优先从日志和资源监控入手，通常能最快定位问题。记住，堆栈信息中往往隐藏着答案。