判断java oom是真实资源短缺还是分配策略错误，关键看错误类型、内存使用模式及堆内对象分布：heap space多因泄漏或堆小，metaspace指向类加载问题，gc overhead limit exceeded提示堆配置与对象存活率失配，direct buffer memory反映nio配置不当，native thread不足源于系统线程限制而非jvm堆。
判断 Java OOM 是程序内存不足（真实资源短缺）还是分配策略错误（配置或使用不当），关键看内存使用模式、错误类型和堆内对象分布，而不是单纯看是否报错。
看错误提示类型，快速定位内存区域
不同 OOM 错误对应不同内存区域，直接反映问题根源：
- java.lang.OutOfMemoryError: Java heap space → 堆内存耗尽，需进一步区分是真不够用，还是泄漏或浪费
- java.lang.OutOfMemoryError: Metaspace → 类元数据过多，常见于频繁加载/卸载类（如热部署、大量动态代理）
- java.lang.OutOfMemoryError: GC overhead limit exceeded → GC 花费 98% 时间却只回收 ≤2% 堆空间，典型信号：堆太小 + 对象存活率高，或存在内存泄漏
- java.lang.OutOfMemoryError: Unable to create new native thread → 系统线程数超限，常因线程池未复用、线程创建失控，而非 JVM 堆问题
- java.lang.OutOfMemoryError: Direct buffer memory → NIO DirectBuffer 分配超出 -XX:MaxDirectMemorySize 或物理内存限制
查堆内存使用曲线和 GC 行为
仅靠一次 OOM 日志无法下结论，要结合运行时监控：
- 如果老年代使用率在 OOM 前长期稳定在 85%~95%，且每次 Full GC 后只回落一点点（比如从 94% → 90%），说明对象持续堆积 → 很可能是内存泄漏或缓存未淘汰
- 如果堆使用率呈阶梯式缓慢上升，GC 频率逐渐增加，但单次回收量不低 → 倾向于分配策略问题（如 Survivor 区过小导致过早晋升，或 Young GC 触发太晚）
- 如果堆使用率在 OOM 前突然飙升（秒级冲到 100%），且无明显 GC 活动 → 可能是单次大对象分配（如读取 GB 级文件进 byte[]），属于程序行为异常，非长期资源不足
- 用 jstat -gc
观察 YGC/FGC 频次、耗时、回收前后容量变化；配合 jstat -gccapacity 看各代实际大小是否与 -Xmx/-Xmn 设置一致
分析堆转储（heap dump），确认对象本质
生成 dump（如用 jmap -dump:format=b,file=heap.hprof
- 按“Retained Heap”排序，找出 Top 3 占用者：如果是业务类（如 OrderCache、UserSessionMap）且实例数异常多、引用链中有 static 或 ThreadLocal → 典型内存泄漏
- 如果大量相同小对象（如 String、HashMap$Node）均匀分布，且每个实例 Retained Heap 小但总数巨大 → 可能是缓存未设上限、日志/监控采集粒度过细等程序设计问题
- 如果大数组（byte[]、char[]）占主导，且其所属对象是临时读取逻辑（如 FileUtil.readFileToByteArray）→ 属于单次操作申请过大内存，应优化分块处理，不是堆整体不够
- 检查 ClassLoader 实例数量：若 WebAppClassLoader 数百个且未被回收 → 类加载器泄漏，导致 Metaspace 持续增长
对照配置与负载，验证是否真缺内存
别假设“加堆就解决”，先做合理性校验：
- 计算理论峰值内存需求：活跃用户数 × 单会话内存占用 + 缓存预估容量 + 安全冗余（一般 20%）。若当前 -Xmx 已高于该值 1.5 倍，还频繁 OOM → 大概率是代码或策略问题
- 检查系统层面：用 free -h 和 cat /proc/meminfo 确认物理内存+swap 是否充足；用 ulimit -u 查最大线程数，避免 “Unable to create new native thread” 误判为 JVM 堆问题
- 观察 GC 日志（加 -Xlog:gc*:file=gc.log:time）：若 CMS/G1 出现 concurrent mode failure 或 evacuation failure，往往是 GC 策略与应用特征不匹配（如 G1RegionSize 设太大导致大对象无法放入），属调优失误
- 同一套代码，在测试环境不 OOM、生产环境 OOM，且生产 QPS/数据量仅高 2~3 倍 → 更可能是缓存 key 设计缺陷、SQL 拉全量数据等程序逻辑瓶颈，而非单纯内存不足
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
