outofmemoryerror: java heap space 是 jvm 堆内存耗尽的严重告警，需预防为主、快速止血：立即摘除节点、禁用内存敏感操作；配置 -xms/-xmx 相等、-xx:+heapdumponoutofmemoryerror；用 mat 分析 hprof 定位泄漏；压测中监控 gc 与对象存活。
遇到 OutOfMemoryError: Java heap space 这类错误，说明 JVM 堆内存已耗尽且无法通过 GC 回收足够空间，程序已处于不可恢复状态。此时不应尝试“捕获并继续运行”，而应聚焦于预防、定位和快速止血。
立即停止写入关键数据
一旦日志中出现堆溢出，JVM 可能已进入不稳定状态：对象分配失败、GC 频繁卡顿、线程挂起。若应用正在处理支付、订单或数据库事务，需确保：
- 暂停新请求接入（如通过负载均衡摘除节点）
- 避免在 finally 或 catch 块中执行日志记录、DB 写入等内存敏感操作
- 不调用
System.gc()—— 它无法解决根本问题，反而加剧停顿
配置合理的堆参数与 OOM 自动处理
JVM 启动时必须明确限制堆上限，并为故障诊断留出线索：
- 设置
-Xms和-Xmx相等（如-Xms2g -Xmx2g），避免动态扩容带来的碎片与不确定性 - 添加
-XX:+HeapDumpOnOutOfMemoryError自动生成堆转储文件（hprof） - 配合
-XX:HeapDumpPath=/path/to/dumps/指定可写路径，避免因权限问题 dump 失败 - 加上
-XX:+PrintGCDetails -Xloggc:gc.log记录 GC 行为，辅助判断是内存泄漏还是容量不足
用工具定位真实瓶颈
堆转储文件（hprof）不是越大越好，关键是分析谁占了最多内存：
- 用 Eclipse MAT 打开 hprof，查看 “Leak Suspects Report” 和 “dominator tree”
- 重点关注 char[]、byte[]、HashMap$Node、ArrayList.elementData 等常见内存大户
- 检查是否有缓存未设上限（如 Guava Cache 缺少 maximumSize）、静态集合持续 add、ThreadLocal 泄漏、大文件流未关闭等典型模式
- 对比多个时间点的堆快照（如每隔 5 分钟自动 dump），观察对象数量是否持续增长
上线前做有效验证
光靠开发环境压测不够，需模拟真实压力下的内存行为：
- 使用 JMeter 或 wrk 对核心接口施加持续流量，同时监控
jstat -gc <pid></pid>的OU（老年代使用量）和FGC（Full GC 次数） - 触发一次手动 Full GC（
jcmd <pid> VM.runFinalization</pid>后jmap -histo:live <pid></pid>），观察对象是否真正释放 - 在预发环境开启
-XX:+UseG1GC并设置-XX:MaxGCPauseMillis=200，观察 G1 是否能及时回收大对象
堆溢出不是异常，而是系统资源告警。它不提供重试机会，也不该被 try-catch 包裹。真正可靠的方案，是让 JVM 在崩溃前留下足够线索，再通过数据确认问题根源，最后用代码约束资源边界。
