真堆内存不够需先确认是否为内存泄漏：检查jstat -gc中OU是否持续上涨且GC后不回落，或用jmap -histo查异常多的类；若OU每次Full GC后升高则极可能泄漏，EU频繁满而OU增长慢则可能是短期对象过多；切忌盲目加大-Xmx，应优先分析堆快照定位持有大量对象的根因。
怎么看是不是真堆内存不够
直接看错误栈里有没有 java.lang.OutOfMemoryError: Java heap space，但别急着加 -Xmx。很多情况是对象泄漏、缓存没清理、大集合误持有，堆空间本身够用，只是垃圾回收不掉。
先确认 JVM 实际堆使用趋势：用 jstat -gc <pid> 看 OU（老年代已用）是否持续上涨且 GC 后不回落；或者用 jmap -histo <pid> 查数量异常多的类，比如 byte[]、HashMap$Node、自定义 DTO 列表。
- 如果
OU每次 full gc 后都比上次高 → 很可能有内存泄漏 - 如果
EU（伊甸园）频繁满但OU增长慢 → 可能是短期对象太多，GC 频繁但没泄漏 - 用
jmap -dump:format=b,file=heap.hprof <pid>抓堆快照后，用 VisualVM 或 Eclipse MAT 分析“Dominator Tree”，重点看谁 hold 住了最多对象
为什么加大 -Xmx 有时反而让问题更隐蔽
堆调大后，OOM 出现得晚，但泄漏对象积累更多，最终 crash 时 dump 文件巨大、分析更慢；同时 GC 停顿时间拉长，影响响应稳定性。
更关键的是：掩盖了代码问题。比如一个 static Map<String, List<Object>> 缓存没做 size 控制或过期策略，-Xmx 从 2G 加到 8G，只是把崩溃从 5 分钟延后到 40 分钟。
立即学习“Java免费学习笔记（深入）”；
- 上线前压测阶段就该用较小堆（如
-Xms512m -Xmx512m）快速暴露泄漏点 - 生产环境加堆前，务必同步加
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps - 避免只调
-Xmx不调-Xms，两者设为相等可减少堆动态扩容开销
哪些常见写法会悄悄吃光堆内存
不是所有大对象都会立刻报错，有些是“温水煮青蛙”式堆积：
-
ThreadLocal没remove()：尤其在线程池场景下，线程复用导致 value 持久存活 - 日志框架里打印了整个
ArrayList或JSONObject.toString()，而集合实际含上万条记录 - 用
new String(byteArr)处理大文件内容，未及时释放原始byte[] - MyBatis 的
resultMap中用了collection嵌套 N+1 查询，返回结果集膨胀数倍 - Spring 的
@Cacheable默认用ConcurrentHashMap存全量，key 是复杂对象、value 是大 POJO，没配maxSize或expireAfterWrite
排查时别漏掉元空间和直接内存
看到 OutOfMemoryError: Java heap space 就只盯堆，容易走偏。JDK 8+ 后，类元数据存在元空间（Metaspace），默认无上限；NIO 的 ByteBuffer.allocateDirect() 分配的是堆外内存——它们爆了不会触发这个错误，但会挤占系统内存，间接导致堆 GC 更困难。
- 检查
jstat -gc <pid>输出中的MU（元空间已用），若持续增长，可能是动态生成类（如 CGLIB、JSON 序列化框架反复生成代理类） - 用
jcmd <pid> VM.native_memory summary看Internal和Direct区域是否异常高 - 加 JVM 参数
-XX:MaxMetaspaceSize=256m防止元空间无限扩张，配合-XX:+PrintGCDetails观察是否频繁 Metaspace GC
真正卡住的，往往不是堆大小，而是谁在一直 new 却没人 clear；不是参数调得不够狠，而是哪行代码偷偷把引用链焊死了。
