Linux上服务突然崩溃

测试反馈，测试环境有台机器服务无法调用，上去一看应用进程都没了，开始以为是大数据量生成报告导致应用发生OOM了，结果登录服务器一看，确并没生成dump文件，这就有点奇怪了，这里总结一下此次排查服务崩溃的原因与排查方法和过程。

一、哪些原因会让我们应用崩溃呢？

一般情况下，我们应用崩溃都是因为应用的OOM（Out Of Memory）导致的，少数是因为部署应用的机器系统资源不足，从而导致应用被操作系统OOM-Killer（Out of Memory Killer）导致崩溃的，极少数是JVM或JDK自身的Bug而导致应用进程崩溃的，下面介绍一下各个情况的排查方法。

二、Java应用发生OOM故障导致崩溃

这种应用发生OOM的比较好排查

1. 直接查看应用的启动参数中的-XX:+HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath=../heap/service-2023-01-05034308.hprof值得到HeapDumpPath参数指定的应用崩溃后存放dump文件的目录。
2. 进入HeapDumpPath参数指定的目录，查看是否产生dump文件，如果存在dump文件，则说明是应用本身故障导致的应用崩溃。
3. 将dump文件进行分析即可得到崩溃原因，推荐使用MAT工具进行分析，比较直观。

三、JVM自身故障导致崩溃

JVM自身故障导致崩溃的，这种情况会生成一个名为hs_err_pid.log错误文件，分析该文件，即可知道导致此次崩溃的原因，如果在应用启动参数里设置了-XX:ErrorFile=./hs_err_pid.log参数，则该文件会保存在参数中指定的路径，如果没有设置该参数，则该文件默认生成在当前应用的工作目录下。

四、操作系统资KILL 掉应用

在Linux系统中，内核有个机制OOM-Killer（Out of Memory Killer），该机制在系统内存不足时将触发，按照一定的策略kill掉应用，这种情况，策略如果选中我们的应用kill掉，则会导致应用崩溃，且应用不会生成dump文件，也有可能其他不兼容情况导致应用崩溃，具体的原因可以通过系统日志查看。

1. 这种情况我们可以去/var/log/messages路径查看系统日志，日志文件可以直接用文本工具打开，此处需要注意日志文件的大小，有些没配置的，该文件可能会特别大，打开前需要注意查看一下文件大小。

查看 messages 文件大小命令。

cd /var/log; ls -al -h | grep messages

当文件不是特别大时，可以直接搜索命令，如果很大，建议使用 less 后再搜索关键字killed process

egrep -i 'killed process' /var/log/messages

如果找出来的结果显示，存在杀进程记录，结合应用崩溃时间，如果崩溃时间与记录时间相吻合则可以判断应用是被系统kill掉了，同时可以查看原因，如果是因为资源不足导致kill应用，此时可以增加资源或排查内存占用异常。

// 日志说明: 一行就是一条数据，基本结构为，产生记录的时间  主机名 子系统名  消息内容
Jan  4 02:12:19 multi-1 kernel: Killed process 26606 (java), UID 1000, total-vm:12853260kB, anon-rss:5517448kB, file-rss:0kB, shmem-rss:0kB

2. 也可以直接查看内核日志，过滤关键词，判断应用是否被系统kill，还可以显示其他异常信息。

dmesg -T | grep java