在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 缓存）