JVM内存分配失败主因是堆不足、分配不合理或内存泄漏，需依日志定位类型后精准调参：统一-Xms/-Xmx、合理设新生代比例、启用堆转储，并结合jstat/jmap监控验证效果。

JVM 内存分配失败，通常表现为 OutOfMemoryError: Java heap space，本质是堆内存不足以容纳新对象。解决的核心思路不是盲目加内存，而是先确认失败原因——是真不够用、分配不合理，还是存在泄漏或碎片。参数调整需结合现象精准干预。

看日志定位具体失败类型

先检查错误日志中的完整异常信息：

• Java heap space：堆内存不足，重点调 -Xms/-Xmx 和新生代比例
• GC overhead limit exceeded：GC 花费 98% 时间却只回收不到 2% 内存，说明堆已严重饱和，可能有泄漏或对象过早晋升
• Metaspace（JDK 8+）或 PermGen space（JDK 7-）：类元数据超限，需调 -XX:MaxMetaspaceSize 或 -XX:MaxPermSize
• Unable to create new native thread：线程栈耗尽，和 -Xss 及系统级线程数限制有关

基础堆参数调整策略

若确认是纯堆空间不足，按以下顺序调整：

Java Api Extractor

从 Java 项目中提取 Controller 层接口定义为 JSON 数据。

下载

• 设置初始堆与最大堆一致，避免运行时扩容开销：-Xms2g -Xmx2g
• 新生代不宜过大（一般占堆 1/4～1/3），防止 Minor GC 频繁；也不宜过小（低于 1/4），否则对象易直接进入老年代：-XX:NewRatio=3（老:新 = 3:1）或 -Xmn512m
• 对 G1 垃圾收集器，可设目标停顿时间：-XX:MaxGCPauseMillis=200，G1 会据此动态调整回收区域
• 启用堆转储便于事后分析：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dump/

应对内存碎片与晋升异常

即使总堆充足，仍报分配失败，很可能是碎片或对象晋升失控：

• G1 出现 to-space exhausted 日志，说明 Survivor 或老年代 Region 空间不连续：可适当增大堆，或调高 -XX:G1HeapRegionSize（如 2M）减少 Region 数量
• CMS 下频繁 concurrent mode failure，说明老年代碎片严重：改用 G1，或加 -XX:+UseCMSCompactAtFullCollection 强制压缩
• 大量对象快速晋升老年代：检查 -XX:MaxTenuringThreshold 是否过低，或 -XX:PretenureSizeThreshold 是否未合理设置大对象阈值

配合监控验证效果

调参后必须用工具验证是否真正缓解问题：

• 用 jstat -gc 2000 观察 O（老年代使用率）是否长期接近 100%，FGC 是否高频
• 开启详细 GC 日志：-Xlog:gc*:file=gc.log:time,uptime,level,tags，关注每次 GC 后老年代占用趋势
• 用 jmap -histo 对比前后对象实例数量，确认是否有某类对象异常堆积