空间分配担保失败本质是老年代内存碎片化导致无法分配连续空间，而非总空间不足；需通过gc日志矛盾信号、jvm参数暴露、调参优化及代码审查四步定位治理。

空间分配担保失败不是内存真的不够，而是老年代虽有空闲，却凑不出连续块来承接晋升对象。JVM 不会立刻抛 OOM，而是按顺序尝试补救：先看能不能直配老年代，再 Minor GC + 晋升判断，最后才走 Full GC。关键在识别失败类型，再针对性干预。

先确认是不是真由担保失败引发

光看“Full GC”日志不够，得抓关键线索：

• GC 日志中出现 Promotion Failed、Failed to allocate from old gen 或 Full GC due to Promotion Failure
• 老年代已用率（OU）不高（比如
• 使用 CMS 时出现 Concurrent Mode Failure；使用 G1 时出现 to-space exhausted 或 Humongous allocation failed
• jstat -gc 输出中 OU 接近 OC，但 GC 后回收量极小——说明是碎片卡住，不是真缺空间

区分失败原因，走不同应对路径

担保失败背后逻辑不同，处理方式也不同：

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 大对象直配老年代失败：对象 ≥ -XX:PretenureSizeThreshold（CMS/ParNew）或 ≥ ½ Region 大小（G1），但老年代没有足够连续空闲块。此时不走晋升流程，直接报 Allocation Failure。解决重点是调 Region 大小（G1）或降低阈值，避免大对象硬塞老年代。
• Minor GC 后晋升失败：Survivor 区存活对象太多，需集体晋升，但老年代最大连续空闲区
• 冒险晋升后仍失败：JVM 判定老年代剩余空间 ≥ 历史平均晋升量，于是允许 Minor GC 后强行晋升，结果发现实际腾不出够用的连续空间。这说明平均值失真，或碎片太严重，需检查晋升阈值（-XX:MaxTenuringThreshold）是否设得过高，导致大量中龄对象堆积。

按 GC 器选择具体调优动作

不同收集器对碎片和担保的处理逻辑差异很大，不能一概而论：

• CMS（已弃用但仍有存量系统）：标记-清除不整理，碎片积累快。应禁用 -XX:+UseCMSCompactAtFullCollection（无效），改用 -XX:CMSFullGCsBeforeCompaction=1 强制 Full GC 后压缩；更稳妥的是迁移到 G1 或 ZGC。
• G1：启用 -XX:G1OldCSetRegionThresholdPercent=5 让低收益高碎片 Region 也能进 Mixed GC；配合 -XX:G1HeapRegionSize=1M 减小 Region 粒度，提升空间利用率；加 -XX:G1ReservePercent=25 预留缓冲防突增。
• ZGC / Shenandoah：并发移动天然抗碎片，基本不会因担保失败触发 Full GC。若仍有 Allocation Failure，大概率是堆总容量不足或 Humongous 对象过大，应优先查对象大小分布，而非调担保参数。

代码与配置层面的预防措施

很多担保失败源于应用行为，调参只是兜底，源头治理更有效：

• 避免在请求链路中临时创建超大 byte[]、String 或 List（如读取整份文件、拼接超长日志）；改用流式处理或分块缓存
• 检查缓存类（如 Guava Cache、Caffeine）的 key/value 是否含隐式大对象，设置合理的 maximumSize 和 expireAfterWrite
• 新生代别设太小：-XX:NewRatio 过大会压缩 Eden，加剧 Minor GC 频率与晋升压力；建议 NewRatio ≤ 3（即新生代占堆 1/4 以上）
• 关闭不必要的 TLAB 浪费：-XX:TLABWasteTargetPercent 设为 1~2，避免线程独占过多未用空间