排查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.txtPrometheus + Grafana：监控 JVM 内存、GC、线程等指标
启用 GC 日志
-Xloggc:/path/to/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStampsJNI问题是什么？
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 崩溃） |
| 日志中的关键字 |
或 |
（崩溃日志） |
| 直接表现 | 抛出异常，可能部分功能不可用，但进程未退出 | 应用突然消失（如终端打印 ） |
| 是否生成堆转储文件 | 如果配置了 ，会生成 文件 | 不会生成堆转储文件，但会生成崩溃日志文件 |
二、实操步骤：快速定位问题类型
1. 第一步：检查进程是否存在
进程还在 → 可能是 OOM 或普通错误（如线程阻塞）。
进程消失 → 可能是 JVM 宕机
2. 第二步：查看应用日志
快速搜索日志中的关键字：
# 查看最近的应用日志（替换为实际路径）
tail -n 100 /path/to/application.log | grep -i "outofmemoryerror"关键日志示例：
OOM：
java.lang.OutOfMemoryError: Java heap spaceJVM 宕机：
没有 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.hprofOOM 发生时，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回收相关信息
