应先诊断内存问题根源而非盲目调大-xmx：用jstat查老年代增长、jmap分析对象分布，确认是否泄漏或突发加载；自动堆转储优于手动；g1非万能，需结合gc日志调优；gc日志须独立配置并轮转。
看到 java.lang.OutOfMemoryError: Java heap space 先别急着加 -Xmx
这个错误表面是堆不够，但直接调大 -Xmx 往往只是掩盖问题——内存泄漏、对象生命周期失控、缓存没清理、GC 策略不匹配，都可能让堆持续增长直到爆掉。
真正该做的是确认「是不是真缺内存」：用 jstat -gc 看老年代是否每次 GC 后占用率都在爬升；用 jmap -histo 查数量异常多的类；重点盯住 byte[]、String、HashMap$Node 这类高频嫌疑对象。
- 如果
jstat显示 Full GC 频繁且老年代回收后仍残留 >70%，大概率是内存泄漏，不是参数问题 - 如果堆使用曲线平缓但某次突发飙升后不回落，检查是否有批量加载、未关闭的流、或临时大对象（比如一次读几百 MB 文件到
byte[]） -
-Xms和-Xmx设成相同值可避免堆动态扩容带来的 GC 波动，但前提是已确认应用真实峰值内存需求
用 jmap 抓堆快照前必须确认 JVM 是否启用了 -XX:+HeapDumpOnOutOfMemoryError
手动触发 jmap -dump:format=b,file=heap.hprof <pid></pid> 在生产环境风险很高：会暂停应用数秒到几十秒，且生成的 heap.hprof 文件可能比堆本身还大（尤其开启压缩时），容易打满磁盘。
更稳妥的做法是一上线就加上这个参数，配合 -XX:HeapDumpPath=/path/to/dumps，让 JVM 在 OOM 时自动落盘。注意路径要有写权限，且磁盘空间预留至少 2 倍于 -Xmx 值。
- OpenJDK 8+ 默认不启用该参数，不加就真得靠
jmap手动抓——但此时应用可能已不可用，快照未必能拿到 - 自动 dump 的文件名默认带时间戳，避免覆盖；但若频繁 OOM，要配日志轮转或监控磁盘使用
- 别用
jvisualvm直连生产进程分析大堆——它会把整个堆拉到本地内存，容易把自己搞崩
-XX:+UseG1GC 不是万能解药，G1 在大堆 + 高分配速率场景下反而容易触发并发模式失败（CMF）
G1 设计目标是可控停顿，但当对象分配速度远超 GC 回收速度时，它会退化成 Full GC，表现和 Serial GC 差不多，甚至更慢。典型现象是日志里反复出现 Concurrent mode failure 或 G1EvacuationPause 后紧跟着 Full GC。
这时不能只调 -XX:MaxGCPauseMillis，而要看实际 GC 日志：G1YoungGeneration 耗时是否稳定、Remembered Sets 占用是否过高、是否频繁触发混合 GC。
- 若老年代晋升太快，优先检查是不是
-XX:G1NewSizePercent太小（默认 2%），导致年轻代过小、提前晋升 - 若 Remembered Set 占用高（日志中
RS scanned时间长），说明跨代引用多，可尝试增大-XX:G1RSetUpdatingPauseTimePercent - 对纯吞吐优先、停顿不敏感的后台任务，
-XX:+UseParallelGC可能比 G1 更稳，尤其在 4~8 GB 堆区间
线上加 -XX:+PrintGCDetails 要配 -Xloggc，别依赖 System.out 重定向
JVM GC 日志默认输出到 stdout，但容器环境或 systemd 服务里，stdout 经常被重定向或截断，等你发现日志没了，OOM 已经发生好几次了。
必须显式用 -Xloggc:/path/to/gc.log 指定独立文件，并搭配 -XX:+UseGCLogFileRotation 和 -XX:NumberOfGCLogFiles=5 防止单文件无限增长。
- Java 9+ 推荐用
-Xlog:gc*:file=/path/to/gc.log:time,tags,level，更灵活，但 Java 8 只能用老式参数 - GC 日志文件权限要和 JVM 进程用户一致，否则写入失败且无提示
- 别把 GC 日志和业务日志混在一个文件里——解析工具（如
gceasy.io）会识别错格式
堆溢出排查最耗时间的从来不是参数怎么写，而是判断「这到底是代码 bug、配置失当，还是负载突变」。日志、监控、堆快照三者缺一不可，少一个就容易在 -Xmx4g 和 -Xmx8g 之间反复横跳。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
