如何排查java程序的宕机和oom？如何解决宕机和oom？

排查oom

用jmap生成我们的堆空间的快照Heap Dump（堆转储文件），来分析我们的内存占用

用可视化工具，例如java中的jhat分析Heap Dump文件，它分析完会通过一个浏览器打开一个可视化页面展示分析结果

根据oom的类型来调整我们的内存配置

java.lang.OutOfMemoryError: Java heap space：堆内存不足。

java.lang.OutOfMemoryError: Metaspace：元空间（类元数据）不足。

java.lang.OutOfMemoryError: Direct buffer memory：直接内存（NIO）不足。

java.lang.OutOfMemoryError: Unable to create new native thread：线程数超出限制。

java.lang.OutOfMemoryError: GC overhead limit exceeded：GC 频繁且回收效率低

调整jvm参数

堆内存不足：

-Xms512m -Xmx4g  # 初始堆和最大堆大小
-XX:+UseG1GC      # 使用 G1 垃圾回收器（适合大堆）

metaspace元空间不足：

-XX:MaxMetaspaceSize=512m  # 限制元空间大小
-XX:+CMSClassUnloadingEnabled  # 启用类卸载（CMS GC）

直接内存不足：

-XX:MaxDirectMemorySize=256m  # 调整直接内存上限

排查宕机（JVM Crash）

1.查看崩溃日志

JVM 崩溃时会生成 hs_err_pid<pid>.log 文件，包含关键信息：

崩溃原因：如 SIGSEGV（非法内存访问）、EXCEPTION_ACCESS_VIOLATION。

堆栈信息：崩溃时的线程堆栈、本地库调用链

2.实时监控工具

jstat：查看 GC 统计信息

jstat -gcutil <pid> 1000  # 每秒打印 GC 情况

jstack：生成线程快照，分析死锁或线程阻塞

jstack <pid> > thread_dump.txt

Prometheus + Grafana：监控 JVM 内存、GC、线程等指标

启用 GC 日志

-Xloggc:/path/to/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps

JNI问题是什么？

JNI（Java Native Interface）是 Java 提供的一种机制，允许 Java 代码与 C/C++ 等本地（Native）代码交互。例如，调用操作系统底层 API 或使用高性能计算库时，可能会用到 JNI。

为什么 JNI 容易出问题？

JNI 是 Java 和本地代码的“桥梁”，但需要手动管理内存和资源

常见问题包括：

内存泄漏：本地代码分配的内存未释放（如 malloc 后未 free）

越界访问：操作数组时越界（如 GetIntArrayElements 后越界写数据）

悬空指针：Java 对象被垃圾回收后，本地代码仍访问其指针

线程安全问题：本地代码未正确处理多线程（如未绑定 JNIEnv 到线程）

兼容性问题：编译的本地库与操作系统或 JVM 版本不兼容（如 32/64 位不匹配）

JNI 问题导致的典型现象

JVM 崩溃：日志中出现 SIGSEGV（段错误）、EXCEPTION_ACCESS_VIOLATION。

内存逐渐耗尽：本地代码内存泄漏，但 Java 堆内存正常。

应用行为异常：数据损坏、随机崩溃（如错误处理指针）。

如何排查 JNI 问题？

查看崩溃日志：JVM 崩溃时生成的 hs_err_pid<pid>.log 文件，定位崩溃的本地方法和线程

本地代码调试：

使用 GDB（Linux）或 WinDbg（Windows）调试本地库。

用 Valgrind（Linux）检查内存泄漏或越界访问。

代码审查：

确保本地代码正确释放资源（如 ReleaseArrayElements）。

避免跨线程使用 JNIEnv（每个线程需通过 AttachCurrentThread 获取）。

简化复现：隔离 JNI 调用部分，编写最小测试用例验证问题

GC日志

什么是GC日志？有什么用？

GC 日志（Garbage Collection Log）是 JVM 垃圾回收过程的详细记录，用于分析内存管理和 GC 性能。

GC 日志的作用

诊断内存问题：

发现频繁 Full GC（可能内存泄漏）

观察对象晋升到老年代的速度（过早晋升导致 OOM）

优化 GC 性能：

分析 GC 暂停时间（Stop-The-World）是否影响应用响应

调整堆大小或选择更合适的 GC 算法（如 G1、ZGC）。

验证配置效果：

确认 JVM 参数（如 -Xmx、-XX:NewRatio）是否生效。

观察分代内存分配是否合理

GC 日志包含哪些信息？

时间戳：GC 发生的时间。

GC 类型：GC（Minor GC）、Full GC。

触发原因：如 Allocation Failure（分配失败）。

内存变化：各分代（YoungGen、OldGen）回收前后的内存大小。

耗时：user（CPU 用户态时间）、real（实际暂停时间）

GC 日志的典型分析场景

频繁 Young GC：

现象：每秒多次 Young GC。

可能原因：新生代太小或短生命周期对象过多。

解决：增大 -Xmn（新生代大小）。

长时间 Full GC：

现象：Full GC 耗时长（如超过 1 秒）。

可能原因：老年代内存不足或内存泄漏。

解决：分析堆转储（Heap Dump）检查大对象

JVM奔溃日志一般会记录什么信息？

1. 基本信息

时间戳：记录崩溃发生的具体时间，精确到毫秒甚至更细的粒度，有助于定位问题出现的时间点。

JVM 版本信息：包括 JVM 的供应商、版本号、构建号等，不同版本的 JVM 可能存在不同的特性和已知问题，这些信息对于分析问题很重要。

操作系统信息：如操作系统的名称、版本、架构（32 位或 64 位）等，因为 JVM 与操作系统的交互可能会影响其稳定性，某些问题可能与特定的操作系统环境相关

2. 崩溃原因信息

错误类型：明确指出 JVM 崩溃的错误类型，如 OutOfMemoryError（内存溢出错误）、StackOverflowError（栈溢出错误）等，这些错误类型为问题的初步定位提供了方向。

异常信息：如果是由异常导致的崩溃，会详细记录异常的类型、消息以及异常发生的调用栈信息。调用栈信息能够显示出异常是在哪些方法中被抛出的，帮助开发人员追踪代码执行路径，找到引发问题的具体代码位置

3. 内存信息

堆内存使用情况：记录 JVM 堆内存的大小、已使用的堆内存量、剩余的堆内存量等信息。通过这些数据可以判断是否存在内存泄漏或内存使用不合理的情况。

非堆内存使用情况：对于 JVM 中的非堆内存，如方法区、本地方法栈等，也会有相应的使用情况记录，有助于全面了解 JVM 的内存占用情况。

垃圾回收信息：包括垃圾回收的次数、不同代（新生代和老年代）的垃圾回收情况、垃圾回收所花费的时间等。垃圾回收如果出现异常，可能导致内存无法及时释放，进而引发 JVM 崩溃，这些信息可以帮助分析垃圾回收是否正常工作

我们一开始什么都不知道的时候，我怎么知道这个是oom还是宕机

一、观察现象：快速区分 OOM 和宕机

特征	OOM（内存溢出）	JVM 宕机（Crash）
进程是否存活	进程可能仍在运行（但无法处理请求）	进程直接退出（JVM 崩溃）
日志中的关键字	`OutOfMemoryError` 或 `java.lang.OOM`	`hs_err_pid<pid>.log` （崩溃日志）
直接表现	抛出异常，可能部分功能不可用，但进程未退出	应用突然消失（如终端打印 `Segmentation Fault` ）
是否生成堆转储文件	如果配置了 `-XX:+HeapDumpOnOutOfMemoryError` ，会生成 `.hprof` 文件	不会生成堆转储文件，但会生成崩溃日志文件

二、实操步骤：快速定位问题类型

1. 第一步：检查进程是否存在

进程还在 → 可能是 OOM 或普通错误（如线程阻塞）。

进程消失 → 可能是 JVM 宕机

2. 第二步：查看应用日志

快速搜索日志中的关键字：

# 查看最近的应用日志（替换为实际路径）
tail -n 100 /path/to/application.log | grep -i "outofmemoryerror"

关键日志示例：

OOM：

java.lang.OutOfMemoryError: Java heap space

JVM 宕机：

没有 OOM 错误，但进程消失。

可能在系统日志中看到 Segmentation fault（Linux）或 EXCEPTION_ACCESS_VIOLATION（Windows）

3.第三步：检查崩溃日志（仅宕机）

如果进程消失，JVM 会生成崩溃日志 hs_err_pid<pid>.log

存在 hs_err_pid.log → JVM 宕机（需分析崩溃原因）。

不存在该日志 → 可能是 OOM 或其他问题

4.第四步：验证 OOM 的堆转储文件

如果配置了 -XX:+HeapDumpOnOutOfMemoryError，OOM 时会生成 .hprof 文件

结论：

存在 .hprof 文件 → OOM。

不存在 → 可能是未配置参数，或非堆内存问题（如 Metaspace OOM）

快速总结

进程活着 + 日志有 OOM 错误 → OOM

进程消失 + 存在 hs_err_pid.log → JVM 宕机

进程消失 + 无崩溃日志 → 可能是系统杀死（如 OOM Killer）或其他原因

面试问答：如果我们的java程序出现了宕机或oom我们该怎么排查

我们一开始并不知道我们的程序出现错误是因为宕机了还是oom？

是因为服务器资源紧张还是java程序配置不合理的原因？

所以我们首先先用top命令去看看服务器整体的内存占用百分比，看看内存是否紧张，我们一般用top命令去查看，但一般都会有现成的监控工具和报警工具，例如普罗米修斯

如果服务器资源不紧张的话，那可能才是java程序本身出了问题

我们要查看java程序是否存活

进程活着 + 日志有 OOM 错误 → OOM

进程消失 + 存在 hs_err_pid.log → JVM 宕机

进程消失 + 无崩溃日志 → 可能是系统杀死（如 OOM Killer）或其他原因

启动Java应用时添加 JVM 参数：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof

OOM 发生时，JVM 会自动生成堆转储文件到指定路径

如果java程序仍然存活，说明出错是因为oom，我们内存oom的话我们会生成一个headdump转储文件

然后我们查看我们的oom的类型

java.lang.OutOfMemoryError: Java heap space：堆内存不足。

java.lang.OutOfMemoryError: Metaspace：元空间（类元数据）不足。

java.lang.OutOfMemoryError: Direct buffer memory：直接内存（NIO）不足。

java.lang.OutOfMemoryError: Unable to create new native thread：线程数超出限制。

java.lang.OutOfMemoryError: GC overhead limit exceeded：GC 频繁且回收效率低

Metaspace属于非堆内存，它的OOM可能和堆OOM表现类似，即JVM进程可能仍然存在，但无法继续加载类，导致应用无法正常运行

我们根据错误类型来调整我们的堆内存的空间配置

如果java程序没有存活，说明就是宕机或者崩溃了

我们的JVM崩溃的时候会生成崩溃日志 hs_err_pid<pid>.log，里面会记录着我们的jvm的崩溃原因信息，jvm信息，内存信息等，然后我们进行分析

这个都是出问题的时候我们根据文件排查的，但是有时候出了问题我们从文件排查不出来，我们就要用jvm工具来排查oom了

我们可以用jmap来手动生成当前堆内存的转储文件headdump，然后用jhat来打开我们的dump文件来分析结果

通过jconsole和普罗米修斯等可视化实时监控工具来查看堆内存，线程，类信息等

jstack分析线程，检查线程是否阻塞在某个对象分配上（例如等待锁导致内存无法释放）

启用gc日志：

-Xloggc:/path/to/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps

通过可视化gc日志GCViewer来查看gc回收相关信息