Allocation Failure 表示 Eden 区分配新对象失败触发 Minor GC，是新生代空间不足的明确信号；它非错误而是正常机制，高频出现才需关注 Eden 大小、对象生命周期或晋升异常。
GC 日志里的 Allocation Failure 不是报错，而是明确告诉你：JVM 在 Eden 区尝试分配一个新对象时，发现没空间了，于是立刻触发了一次 Minor GC。
Allocation Failure 是新生代分配失败的直接信号
它只出现在 Minor GC 日志中（如 [GC (Allocation Failure)），说明问题出在年轻代，和老年代是否快满无关。常见表现包括：
- 日志中
PSYoungGen或ParNew前后数值差很大，但回收后 Eden 使用量仍接近上限，说明对象存活率高或晋升太快 - 同一秒内连续出现多次
(Allocation Failure)，大概率是 Eden 区太小，或者应用正批量创建中等生命周期对象（比如解析 JSON、组装 DTO） - 每次 GC 后有少量但稳定的数据从年轻代升到老年代（例如日志里
522739K->156516K和367523K->1293K差值约 16K），说明存在一批“活过一次 GC”的对象
别把 Allocation Failure 当异常，但要警惕高频发生
单次 (Allocation Failure) 完全正常，所有健康 Java 应用都会遇到。真正需要关注的是频率和上下文：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 刚启动时频繁出现？可能是预热阶段对象激增，属合理现象
- 运行数小时后每秒都来几次？说明 Eden 配置偏小，或代码中存在隐式大对象（如未复用的
byte[]、StringBuilder缓冲区） - 伴随 GC 时间明显变长（比如从 2ms 涨到 20ms+）？可能年轻代碎片化，或对象复制成本升高（如大量引用需更新）
对比看 Ergonomics 才能定位层级问题
Full GC (Ergonomics) 和 GC (Allocation Failure) 经常被一起分析，因为它们反映不同层面的压力：
立即学习“Java免费学习笔记（深入）”；
-
Allocation Failure是“我分不了新对象了”，问题在 Eden 空间管理 -
Ergonomics是“我看老年代快撑不住了，先整理一下”，问题在代际平衡或晋升策略 - 如果
Allocation Failure很多，紧接着又频繁出现ErgonomicsFull GC，基本可以断定：年轻代太小 → 对象过早晋升 → 老年代压力骤增
快速判断该不该调参的依据
打开最近一小时 GC 日志，统计两个数字：
- Minor GC 平均间隔是否短于 10 秒？如果是，优先考虑加大
-Xmn或调整-XX:NewRatio - 每次 Minor GC 后，老年代增量是否持续超过 1MB/次？说明对象生命周期设计不合理，该查缓存、流式处理或对象复用
- Eden 区回收后利用率是否长期高于 85%？说明 GC 效果打折，不是空间不够就是对象“假死”（如被静态集合意外持有）
