在Java开发中，内存问题向来是常见且棘手的挑战。相比于日常编写具有确定性的业务代码，内存问题往往具有极强的偶发性和滞后性，排查难度呈指数级上升。本文将首先厘清“内存溢出（OOM）”与“内存泄漏（Memory Leak）”的核心区别，并梳理常规的排查思路。在后续的文章中，我还会针对“内存泄漏”这一重灾区，提供一套具体、可落地的深度排查实战指南

一、 核心区别

• 内存泄漏 (Memory Leak)
  • 定义：指程序中已经分配的内存，由于某些原因（如对象引用未释放），无法被垃圾回收器（GC）回收
  • 本质：是一种状态或过程，属于“该还的没还”。就像水桶底有个小洞，水（内存）在不知不觉中慢慢流失，导致可用空间越来越少
  • 表现：程序通常不会立即崩溃，而是运行时间越长，占用的内存就越多
• 内存溢出 (Out of Memory, OOM)
  • 定义：指程序在申请内存时，系统或JVM没有足够的可用内存供其使用。
  • 本质：是一种错误或结果，属于“借不到了”。就像水桶已经装满了水，再也倒不进去了
  • 表现：程序会直接抛出异常（如java.lang.OutOfMemoryError），导致程序崩溃或无法响应

两者的关系：内存泄漏是导致内存溢出的常见原因之一。随着泄漏的累积，可用内存越来越少，最终在申请新内存时就会触发OOM。但OOM也可以独立发生，例如一次性加载一个几百兆的文件，而系统堆内存设置较小，这会直接导致OOM，但代码中并没有内存泄漏

二、 排查方法与流程

无论是排查内存泄漏还是OOM，核心思路都是：保留现场 → 分析原因 → 定位代码 → 修复验证

1. 紧急止损（针对线上OOM）

当线上服务发生OOM时，首先要做的是恢复服务

• 摘流量与重启：先从负载均衡中摘掉流量，重启实例以恢复服务
• 保留现场：重启前务必将.hprof堆快照文件和gc.log拷贝到安全位置，否则重启后现场就没了

2. 区分OOM类型（看错误日志）

查看日志中java.lang.OutOfMemoryError:后面的具体信息，不同类型的OOM指向不同的原因：

• Java heap space：堆内存不足
• Metaspace：元空间不足。通常是因为动态生成大量类（如反射、CGLib代理）或类加载器泄漏
• Direct buffer memory：直接内存不足。NIO操作频繁，ByteBuffer.allocateDirect分配的内存未及时释放

3. 抓取内存快照

• 事前配置：建议在JVM启动参数中加入-XX:+HeapDumpOnOutOfMemoryError和-XX:HeapDumpPath=/path/to/dump.hprof，让JVM在发生OOM时自动生成堆快照
• 手动导出：如果未配置自动dump，可在OOM后（服务未重启前）使用jmap -dump:format=b,file=heap.hprof <pid>命令手动导出
• 在线诊断：使用Arthas的memory命令查看内存状态，或使用heapdump命令生成堆转储文件，无需重启服务即可排查

4. 深度分析（核心环节）

使用内存分析工具（如Eclipse MAT、JProfiler、VisualVM或Android Profiler）打开.hprof文件进行分析：

• 查看 Dominator Tree（支配树）：找出占用内存最多的对象（内存大户）
• 分析引用链（Path to GC Roots）：查看这些大对象是被谁引用的，理解它们为何未被回收（例如是否被静态集合、长生命周期的缓存持有）
• 对比快照：捕获不同时间点的堆快照进行对比，找出数量持续增长的对象类型，这些通常是内存泄漏的根源

5. 常见泄漏场景与修复

定位到问题对象后，需回溯代码进行修复。常见的内存泄漏场景包括

• 静态集合类：全局的List、Map等无限制地添加数据，且从未清理
• 资源未关闭：数据库连接、IO流、网络连接等未在finally块或try-with-resources中正确关闭
• 监听器/回调未注销：注册了事件监听器，但在组件销毁时忘记移除。
• 不合理缓存：使用了没有容量限制和过期策略的缓存（如普通的HashMap），应改用带有淘汰策略的缓存（如 Guava Cache 或 LRU 缓存）