堆内存溢出本质是对象持续创建或未释放致堆耗尽，非物理内存不足；日志含“java heap space”可确认为堆区问题，配合jstat、mat等工具区分泄漏与真容量不足并修复。
JVM 堆内存溢出（java.lang.OutOfMemoryError: Java heap space）是最常见的 OOM 类型，本质是对象持续创建或未释放，导致堆空间耗尽。它不等于物理内存不足，而是 JVM 堆上限被触达——哪怕机器还有空闲内存，只要 -Xmx 设得太小或代码不合理，照样会崩。
看懂错误日志，快速定位区域
出现堆溢出时，日志末尾通常带明确提示：
-
java.lang.OutOfMemoryError: Java heap space→ 确认是堆区问题，不是栈、元空间或直接内存 - 紧随其后常有
Dumping heap to xxx.hprof→ 表明已按-XX:+HeapDumpOnOutOfMemoryError自动转储，文件可直接分析 - 堆栈中若频繁出现某类（如
ArrayList、String、业务实体类）的构造或 add 操作 → 暗示该类对象堆积严重
区分泄漏与溢出，决定修复路径
关键第一步：判断是“不该留的没走”（内存泄漏），还是“该留的太多”（真容量不足）。
- 内存泄漏特征：同一类对象数量随时间持续增长；GC 后老年代存活对象不降反升；MAT 分析显示大量对象通过静态集合、缓存、监听器等强引用链连到 GC Roots
- 真容量不足特征：流量/数据量突增（如秒杀、报表导出）；一次性加载全表数据；大对象（如百MB级 byte[]、图片缓存）集中创建；堆 dump 中对象类型合理但总量远超预期
常用排查与修复手段
无需凭感觉猜，靠工具+逻辑闭环验证：
- 用
jstat -gc <pid></pid>观察 Young GC / Full GC 频率和回收效果，若 Full GC 后老年代仍居高不下，大概率是泄漏 - 用 VisualVM 或 JConsole 实时监控堆使用曲线，配合业务操作看内存是否阶梯式上涨且不回落
- 用 MAT 打开 hprof 文件 → “Leak Suspects” 报告直指可疑对象 → “Dominator Tree” 查看最大内存占用类 → “Path to GC Roots”（排除弱/软引用）定位强引用源头
- 代码重点检查：静态集合未清理、缓存无淘汰策略、流/连接未 try-with-resources、监听器注册后未反注册、线程局部变量（ThreadLocal）未 remove()
参数与架构层面优化
调大堆不是万能解，但往往是必要缓冲；真正治本要落在设计上：
- JVM 参数建议：设
-Xms=-Xmx避免动态扩容开销；加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path留证 - 数据库查询必须分页，禁用
SELECT * FROM huge_table；大数据处理改用流式（Stream API + 数据库游标）或分批拉取 - 缓存场景优先选
LinkedHashMap（LRU）或 Caffeine，避免无界ConcurrentHashMap；图片/文件缓存考虑磁盘落地 - 避免在循环内反复 new 大对象；高频短生命周期对象考虑对象池（如 Apache Commons Pool），但需权衡复杂度
