OOM主因分内存泄漏与配置不足：泄漏表现为堆使用率缓升、GC回收差、老年代长期>85%且Dump中存在稳定引用链；配置不足则堆陡升后即满、GC能有效回收但容量不足，调大-Xmx可缓解。
关键看堆内存使用趋势和对象存活状态，而不是只盯着报错信息。
看堆内存增长是否“停不下来”
内存泄漏导致的OOM，通常表现为：应用运行一段时间后，堆内存使用率持续缓慢上升，GC后回收效果越来越差，最终在远低于-Xmx设定值时就触发OOM。比如-Xmx4g，但实际只用了2.8g就崩了，且老年代占用长期高于85%。
硬件配置不足（即堆设得太小）导致的OOM，往往出现在启动后短时间内——尤其是一次性加载大量数据、初始化大缓存或批量处理时。堆使用曲线陡升，很快打满，但GC仍能较干净地回收（比如每次Full GC后老年代回落到20%以下），只是容量确实不够用。
分析堆转储（Heap Dump）里的对象分布
用MAT、JProfiler或VisualVM打开OOM时自动生成的hprof文件：
立即学习“Java免费学习笔记（深入）”；
- 内存泄漏典型特征：存在大量同一类对象（如UserEntity、ResponseDTO），且它们都通过一条稳定的引用链（比如static Map → ThreadLocal → ArrayList → 对象实例）连到GC Roots；这些对象本该被回收却一直“活着”。
- 配置不足典型特征：堆中对象种类多、生命周期短，没有明显占主导的“异常类”，但整体对象数量巨大、平均大小合理；常见于List/Map里塞了几十万条业务数据，或缓存未做大小限制。
结合GC日志判断回收效率
开启-XX:+PrintGCDetails -Xloggc:gc.log参数后观察：
- 如果频繁出现“GC overhead limit exceeded”，且每次GC只回收几MB，但耗时几百毫秒——大概率是泄漏（对象堆积导致GC徒劳挣扎）。
- 如果GC频率不高，但某次Young GC后晋升到老年代的对象暴增，紧接着Full GC也收不回来——更可能是单次负载超限，堆不够用。
复现时做“减法验证”
这是最直接的区分方式：
- 把-Xmx临时调大一倍（比如从2g→4g），重启应用，模拟相同操作。如果OOM消失或大幅延后，倾向于是配置不足；
- 如果调大后依然在相似时间点、相似内存用量下崩溃，且堆转储中仍有稳定增长的可疑对象链——基本可锁定为内存泄漏。
