网硕互联帮助中心好的，这是一份排查 Java 内存溢出（OutOfMemoryError, OOM）的实战指南：
Java 内存溢出（OOM）排查实战指南
Java 内存溢出是开发中常见且棘手的问题。当 JVM 无法分配更多内存以满足对象创建或元数据需求时，就会抛出 OutOfMemoryError。本指南将帮助你系统地排查和解决 OOM 问题。
第一步：识别 OOM 类型
OOM 有多种类型，每种对应不同的内存区域。首先需确定错误类型：
java.lang.OutOfMemoryError: Java heap space
- 最常见类型，表示 堆内存 不足。
- 通常是创建了过多对象或存在内存泄漏（对象无法被 GC 回收）。
java.lang.OutOfMemoryError: Metaspace (或 PermGen space，在较老版本中)
- 表示 元空间 (存储类元数据、方法信息等) 不足。
- 通常由加载过多类、动态生成类（如反射、CGLib、ASM）或元空间配置过小引起。
java.lang.OutOfMemoryError: Unable to create new native thread
- 表示 线程栈 资源不足。
- 通常是创建了过多线程，超出了系统或 JVM 限制。
java.lang.OutOfMemoryError: Direct buffer memory
- 表示 直接内存 (堆外内存，由 ByteBuffer.allocateDirect() 分配) 不足。
- 通常与 NIO 操作相关。
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
- 尝试分配一个大于 JVM 允许最大数组大小的数组。
java.lang.OutOfMemoryError: GC overhead limit exceeded
- GC 花费了过多时间（超过 98%）但回收效果极差（每次回收释放的内存少于 2%），JVM 判定继续运行无意义。
java.lang.OutOfMemoryError: Compressed class space
- 与压缩类指针相关的特定区域内存不足。
排查关键： 查看错误日志或异常堆栈信息，明确是哪一种 OOM。
第二步：收集关键信息
获取完整错误日志：
- 包括 OOM 类型、发生时间、堆栈跟踪（stack trace）。堆栈信息能指示 OOM 发生时程序正在执行的操作。
获取 JVM 配置参数：
- 特别是内存相关的参数：
- -Xms (初始堆大小)
- -Xmx (最大堆大小)
- -XX:MetaspaceSize / -XX:MaxMetaspaceSize
- -XX:MaxDirectMemorySize
- -Xss (每个线程栈大小)
- 使用的 GC 算法（如 -XX:+UseG1GC）
- 其他相关参数（如 -XX:+HeapDumpOnOutOfMemoryError）
系统资源信息：
- 物理内存总量、可用内存。
- CPU 使用率。
- 操作系统限制（如用户进程数、虚拟内存大小）。
第三步：分析内存使用情况
启用堆转储 (Heap Dump)：
- 在启动 JVM 时添加参数 -XX:+HeapDumpOnOutOfMemoryError。这样在发生 OOM 时，JVM 会自动生成一个堆转储文件（通常是 .hprof 文件）。
- 如果问题可重现，也可以在问题发生前手动触发转储：
- 使用 jmap 工具：jmap -dump:format=b,file=heapdump.hprof <pid> (替换 <pid> 为 Java 进程 ID)。
- 使用 jcmd 工具：jcmd <pid> GC.heap_dump /path/to/heapdump.hprof。
分析堆转储文件：
- 使用内存分析工具（Memory Analyzer Tool, MAT）是 最有效 的方法。
- 安装 MAT： 下载 Eclipse MAT (Memory Analyzer Tool)。
- 打开 .hprof 文件： 使用 MAT 加载堆转储文件。
- 识别问题：
- Leak Suspects Report (泄漏嫌疑报告)： MAT 会自动生成报告，列出可能导致泄漏的对象和引用链。这是 首要查看 的地方。
- Histogram (直方图)： 查看按类或类加载器统计的对象数量和占用内存大小。重点关注数量异常多或占用内存大的类。
- Dominator Tree (支配树)： 查看哪些对象持有了大量内存，以及它们的引用路径。这有助于找到内存消耗的“根”。
- 对比快照： 如果能在 OOM 前获取一个堆快照，在 MAT 中对比两个快照，可以清晰地看出哪些对象在增长。
- 其他可选工具：jvisualvm (JDK 自带), YourKit, JProfiler 等。
监控 GC 活动：
- 使用 jstat 工具监控 GC 统计信息：
- jstat -gcutil <pid> 1000 (每 1000 毫秒打印一次 GC 统计信息)
- 关注 S0C/S1C/S0U/S1U (Survivor 区容量/使用量)，EC/EU (Eden 区容量/使用量)，OC/OU (老年代容量/使用量)，MC/MU (元空间容量/使用量)，YGC/YGCT (Young GC 次数/时间)，FGC/FGCT (Full GC 次数/时间)。
- 使用 jcmd <pid> GC.heap_info 查看堆内存分布。
- 启用 GC 日志：
- 添加 JVM 参数 -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log。
- 分析 GC 日志，查看 GC 频率、耗时、回收效果（如老年代是否持续增长）。
分析线程情况：
- 对于 Unable to create new native thread，检查线程数量：
- 使用 jstack <pid> 获取线程堆栈信息，统计线程数量。
- 使用 top -H -p <pid> (Linux) 或 Process Explorer (Windows) 查看进程的线程数。
- 分析 jstack 输出，查看是否有大量线程阻塞在相同位置或执行相同任务。
分析直接内存使用：
- 对于 Direct buffer memory，排查使用 ByteBuffer.allocateDirect() 或 NIO 相关操作的代码。
- 使用 jcmd <pid> VM.native_memory 查看 Native Memory Tracking (NMT) 信息（需在启动时开启 -XX:NativeMemoryTracking=summary 或 detail）。
第四步：定位问题根源与修复
根据分析结果，针对性解决：
-
Java heap space / GC overhead limit exceeded：
- 内存泄漏： 根据 MAT 分析结果，找到并修复泄漏点。常见原因：
- 静态集合类（如 static HashMap）无节制地增长。
- 未关闭资源（数据库连接、文件流、网络连接等），导致关联对象无法释放。
- 监听器/回调未正确注销。
- 缓存使用不当，缺乏淘汰策略。
- 合理设计： 避免创建生命周期过长的大对象（如超大数组、集合）。考虑对象池化。
- 优化 GC： 调整堆大小 (-Xmx)，选择合适的 GC 算法和参数（如 G1 的 -XX:MaxGCPauseMillis）。
- 调大堆： 如果确实是应用需要大量内存且无泄漏，可适当增加 -Xmx（需确保物理内存足够）。
- 内存泄漏： 根据 MAT 分析结果，找到并修复泄漏点。常见原因：
-
Metaspace / Compressed class space：
- 检查是否有框架（如 Spring AOP, Hibernate）动态生成大量类。
- 排查自定义类加载器是否频繁加载/卸载类。
- 增加元空间大小：-XX:MaxMetaspaceSize。
- 减少动态类生成（如果可能）。
-
Unable to create new native thread：
- 优化代码，减少线程创建（使用线程池）。
- 调整 -Xss 减小单个线程栈大小（谨慎操作，可能导致 StackOverflowError）。
- 检查操作系统对用户进程或线程数的限制 (ulimit -u)，必要时调整。
-
Direct buffer memory：
- 检查使用直接内存的代码（如 Netty, NIO），确保 ByteBuffer 在使用后被清理（或显式调用 ((DirectBuffer) buffer).cleaner().clean()，但需谨慎）。
- 增加直接内存限制：-XX:MaxDirectMemorySize。
-
Requested array size exceeds VM limit：
- 检查尝试分配超大数组的代码逻辑，避免分配超过 Integer.MAX_VALUE – 8 大小的数组。
第五步：验证与预防
- 验证修复： 在测试环境或灰度环境中验证修复措施是否有效。
- 持续监控： 在生产环境配置监控（如 Prometheus + Grafana），跟踪关键指标：
- JVM 内存各区域使用量（Heap, Metaspace, Direct Buffer）。
- GC 频率和耗时。
- 线程数量。
- 压力测试： 定期进行压力测试和长时间稳定性测试，提前暴露潜在问题。
- 代码审查： 关注资源管理（try-with-resources）、缓存使用、集合类管理等。
总结： OOM 排查是一个系统工程，需要结合日志分析、工具使用（jmap, jstack, jstat, MAT）和代码审查。关键在于快速准确定位 OOM 类型和内存消耗热点，再针对性优化代码或调整 JVM 配置。持续监控和预防性措施同样重要。
评论前必须登录！
注册