当前位置：首页 > news >正文

java 进程崩溃的定位

news 2026/6/29 23:39:18

在 CentOS 上排查 Java 程序“为什么中断”最可靠的办法是把 JVM 自己生成的崩溃日志、操作系统日志、内核日志三件事放在一起看。下面给出一份可直接落地的排查顺序，全部命令都在 CentOS 7/8 验证过，按 1→2→3→4 看完基本就能定位是代码问题、资源问题还是系统直接把进程杀掉了。

一.先找 JVM 崩溃时自动生成的 “hs_err_pidXXX.log”
只要进程是因为 JVM 自身故障（例如 SIGSEGV、SIGBUS、本地库崩溃）退出，JVM 会在工作目录或`-XX:ErrorFile=`指定的目录下生成`hs_err_pid<PID>.log`。
快速定位命令：

# 全局搜最近一次生成的崩溃日志 find / -type f -name "hs_err_pid*.log" -mtime -1 2>/dev/null | xargs ls -lt | head

找到文件后直接less查看，重点看第一段 “SIGXXXX” 行和 “Problematic frame” 行，就能知道是本地库崩了还是 JIT 代码段异常。

二、.如果第 1 步没找到，说明不是 JVM 自己崩溃，而是被“外力”杀掉的，继续查系统日志。
CentOS 把“杀进程”事件全部记在`/var/log/messages`（RHEL/CentOS 7）或`/var/log/syslog`（部分衍生版）。
用关键字一次性过滤：

# 看内存耗尽触发的 OOM Killer grep -i 'killed process.*java' /var/log/messages # 再看段错误 grep -i 'segfault.*java' /var/log/messages

2.1 如果出现 “Out of memory: Kill process … java …” 就能确认是系统内存耗尽，内核主动把 Java 进程干掉，此时 JVM 来不及生成 hs_err 文件

例如出现：Out of memory: Killed process 4018654 (java) total-vm:5611964kB, anon-rss:2122832kB, file-rss:11328kB, shmem-rss:0kB, UID:0 pgtables:4992kB oom_score_adj:0

以上日志表示：系统物理内存耗尽，Linux OOM-Killer 把 Java 进程 4018654 杀掉了。
JVM 来不及生成 hs_err 文件，所以你刚才find不到任何东西。下面给你一份“立即止血 + 长期监控”的完整方案，全部命令在 CentOS 7/8 直接可用。

2.1.1立即止血——先让服务能活下来（重启服务）

2.1.2、定位为什么内存会炸

看 JVM 启动参数里堆最大设了多少

ps -ef | grep java | grep -oP '\-Xmx\K[\d]+[gGmMkK]?'

假设输出2048m，而机器物理内存只有 2 GB，那堆 + Metaspace + 代码缓存 + 原生内存 > 物理内存，OOM 是迟早的事。

2.1.3.用`free -h`和`top`/`htop`实时观察

free -h

如果 “available” 长期 < 200 MB，就证明内存本身就不够，而不是内存泄漏。

2.1.4.怀疑 Java 堆外内存泄漏，用 NMT 快速验证
启动参数里加上

-XX:NativeMemoryTracking=summary -XX:+UnlockDiagnosticVMOptions

jcmd <pid> VM.native_memory summary

2.2、长期监控——避免下次再被 OOM

2.2.1 给 systemd 服务加内存限制，提前让 JVM 自己 OOM，而不是系统杀

[Service] MemoryMax=3G # 物理内存的 70% 左右 MemorySwapMax=0 # 禁止用 swap

这样当 JVM 要超 3 GB 时 systemd 会发 SIGTERM，应用可以优雅 shutdown，同时留下日志。

用sar或node_exporter把内存曲线落到 Prometheus，
规则示例：
(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.1
低于 10 % 就报警，比事后翻 messages 强。
如果就是业务峰值需要大内存，而机器只有 2 GB，那最根本的办法是
- 升配机器
- 或者把 JVM 最大堆降到物理内存的 50% 以内，例如 1 GB 机器只给-Xmx512m，并打开 swap（性能会掉，但不会莫名其妙被杀）。

2.2.2 用`sar`看历史（如果装了 sysstat）

# 昨天 14:00-15:00 的内存利用率，1 分钟粒度 sar -r -f /var/log/sa/sa$(date -d yesterday +%d) -s 14:00:00 -e 15:00:00 | less

关注kbmemused和%memused哪一分钟突然飙到 95 % 以上，再对应/var/log/messages里的“Killed process”时间戳，就能知道是谁在那一瞬间把内存涨满。

2.2.3 如果没装`sar`，直接翻`/var/log/messages`里 OOM 记录前后 30 秒的进程列表：

# 假设 OOM 发生在 14:23:05 sed -n '/14:23:00/,/14:23:10/p' /var/log/messages | grep -E 'java|python|nginx|mysqld|docker'

经常能看到宝塔后台“计划任务”里某个一次性 Python 脚本、MySQL 慢查询、或者 Docker 临时容器把内存瞬间拉满，杀完以后内存又回落，所以你事后看只剩 1.5 GB。

2.2.4 想以后秒级留证，给机器加一套最简单监控：

yum install -y htop atop # 让 atop 每 30 秒写一次快照 sed -i 's/LOGINTERVAL=600/LOGINTERVAL=30/' /etc/sysconfig/atop sed -i 's/LOGGENERATIONS=28/LOGGENERATIONS=7/' /etc/sysconfig/atop # 2. 立即生效 systemctl restart atop

上面设置的是 atop 每 30 秒记一次快照，7 天后自动滚删，足够你下次 OOM 时“回放”抓凶手

完成后 30 秒即可在/var/log/atop/看到atop20251212这类日志文件，用atop -r /var/log/atop/atop20251212就能回放 OOM 当时的内存排行榜

下次再被 OOM，只要atop -r /var/log/atop/atop_YYYYMMDD翻到死机时间点，就能按m键看内存排行榜，谁涨谁降一目了然。

三、.用`dmesg`查内核现场（时间戳更准）
`dmesg`会打印出段错误、OOM Killer、SIGKILL 等信号的发送记录，而且带微秒级时间戳，方便和你应用日志里的时间对齐。

dmesg -T | grep -i -E 'java|killed process|segfault'

四、如果前面三步都空，则可能是优雅退出（有人`kill -15`、自己调了`System.exit`、容器重启策略等）。

这时只能把应用自己的 stdout / gc 日志 / systemd 服务日志拿出来对照时间：

# systemd 启动的 Java 服务 journalctl -u your-java-service --since "2025-12-11 14:00:00" # 或者 tomcat 这类自带日志 tail -n 5000 -f /usr/local/tomcat/logs/catalina.out | grep -i 'shutdown|stop|exit'

查看全文

http://www.cnnetsun.cn/news/14345.html