分配速率通过Eden区两次Young GC间内存变化与时间差估算，如间隔0.8秒、Eden回收前均占120MB，则速率为150 MB/s；需结合GC频率与停顿判断是否异常。
通过 JVM 垃圾回收日志分析对象分配速率，核心是观察 年轻代（尤其是 Eden 区）的回收频率与每次回收前后的内存变化，从中反推应用每秒新创建对象的平均大小。这不是直接打印“分配了多少字节”，而是借助 GC 日志中的关键字段做估算。
看清楚日志中 Eden 区的使用量变化
启用详细 GC 日志（如 -Xlog:gc*,gc+heap=debug 或旧版 -XX:+PrintGCDetails）后，每次 Young GC 日志类似：
[GC (Allocation Failure) [PSYoungGen: 123456K->12345K(131072K)] 189012K->78456K(419430K), 0.0456789 secs]重点关注三部分：
- PSYoungGen: A->B(C)：A 是 GC 前 Eden + Survivor 中存活对象总大小（单位 KB），B 是 GC 后年轻代占用，C 是年轻代总容量
- 括号外的 189012K->78456K 是整个堆的变化，但分配压力主要体现在年轻代
- Allocation Failure 表明这次 GC 是因为 Eden 满了触发的——这是估算分配速率最可靠的信号
用两次 GC 时间差和 Eden 回收量估算分配速率
当 Eden 区因填满而触发 GC，可近似认为：GC 前 Eden 几乎被新对象占满（忽略 Survivor 晋升和浮动垃圾）。因此：
立即学习“Java免费学习笔记（深入）”；
- 单次 GC 前 Eden 占用 ≈ Eden 容量 − GC 后年轻代占用 + GC 前 Survivor 中已有的存活对象；实践中常简化为：≈ Eden 容量 − GC 后年轻代占用（因 Survivor 通常占比小且相对稳定）
- 若连续两次 Young GC 时间戳分别为 t1 和 t2（单位秒），对应 Eden 回收前占用分别为 E1、E2（KB），则平均分配速率 ≈ (E2 − E1) / (t2 − t1)（KB/s）
- 例如：两次 GC 间隔 0.8 秒，Eden 回收前分别用了 120MB 和 120MB（稳定），说明分配速率为 ≈ 120MB / 0.8s = 150 MB/s
结合 GC 频率和停顿时间判断是否异常
分配速率本身无好坏，需结合系统表现看是否合理：
- 如果 Young GC 每秒发生多次（如间隔
- 若分配速率稳定在 50 MB/s，但 GC 间隔从 2 秒缩短到 200ms，可能是内存泄漏或缓存膨胀，需查对象类型（配合 -XX:+PrintGCDetails + jstat -gc 或 jmap -histo）
- 注意：大对象（≥ Eden 半区）会直接进老年代，不经过 Eden 分配，这类对象不会体现在上述 Eden 填充速率里，需额外关注老年代增长和 Full GC
推荐搭配工具提升分析效率
纯手工解析日志易出错，建议组合使用：
- gclogviewer（开源 Web 工具）：上传 GC 日志自动绘图，直观显示 Eden 使用趋势、GC 间隔、吞吐量
- gceasy.io（在线服务）：解析后给出分配速率估算值、GC 健康评分、瓶颈提示（如 “High allocation rate detected”）
- jstat -gc <pid> 1000：实时查看各代内存使用和 GC 次数，快速验证日志结论（如 S0C/S1C 稳定、EC 接近 EC 的值，说明 Eden 利用率高）
