JVM内存分配速率通过Young GC间隔与Eden区分配量计算得出，公式为：分配速率≈Eden分配量/Δt（MB/s）；需用-XX:+PrintGCDetails等参数获取日志，取稳定期多组样本求平均值，超500 MB/s需优化。
评估 JVM 内存分配速率，核心是通过 GC 日志中年轻代（尤其是 Eden 区）的回收频率与每次回收前后的内存变化来反推应用每秒分配了多少对象。
看 Young GC 频率和 Eden 使用量变化
每次 Young GC 前，Eden 区几乎被填满；GC 后 Eden 被清空（或基本清空），Survivor 区仅保留少量存活对象。因此：
- 记录两次连续 Young GC 的时间戳（如 2026-09-24T22:15:03.218 和 2026-09-24T22:15:03.742），算出间隔 Δt（单位：秒）
- 提取前一次 GC 前 Eden 使用量（如 Eden: 1024.0M->0.0M），即该次分配总量 ≈ 1024 MB
- 分配速率 ≈ Eden 分配量 / Δt（单位：MB/s）。上例中 ≈ 1024 MB / 0.524 s ≈ 1954 MB/s
注意区分“分配”和“晋升”
GC 日志中的 [PSYoungGen: 1024M->42M] 表示 Young 区从 1024M 降到 42M，其中：
- 约 1024M 是本次 GC 前新分配的对象总量（近似值，忽略 Survivor 晋升和部分直接分配到老年代的情况）
- 42M 是幸存并复制到 Survivor 的对象，不计入本轮分配量
- 若日志中频繁出现 [ParNew: ... (promotion failed)] 或老年代增长快，说明有大量对象快速晋升，此时 Eden 分配速率仍可照常估算，但需额外关注晋升率
用 -Xloggc + -XX:+PrintGCDetails 提取关键字段
确保开启以下 JVM 参数获取结构化日志：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- -Xloggc:/path/to/gc.log
- -XX:+PrintGCDetails -XX:+PrintGCDateStamps
- Java 9+ 推荐用：-Xlog:gc*,gc+heap=debug:file=/path/to/gc.log:time,tags,uptime
重点关注每行中的 [Eden: A->B]、[Times: user=..., sys=..., real=...]，real 时间即 GC 实际耗时，也是计算间隔的依据。
排除 GC 暂停干扰，取稳定窗口平均值
刚启动或突发流量时分配速率波动大，应选取业务平稳期（如连续 1~5 分钟）内多组 Young GC 样本：
- 统计 10 次 Young GC 的 Eden 分配量总和（如累计 8250 MB）和对应总时间跨度（如 4.3 秒）
- 平均分配速率 = 总分配量 / 时间跨度（不是 / GC 次数）
- 若发现速率 > 500 MB/s 且持续，说明对象创建压力大，可能需优化热点代码或调整 -Xmn
