要查看JVM各内存区域实际占比，需结合运行时真实分配量计算：用jstat -gc或-gcutil实时查使用率；jmap -heap验证静态配置比例；ManagementFactory编程获取精确池级占比；参数仅反映理论比例。
要查看 JVM 各内存区域的实际占比（比如 Eden 占新生代多少、新生代占堆多少、Metaspace 占非堆多少），关键不是只看启动参数，而是结合运行时真实分配量计算——因为很多区域大小是动态调整的，且不同 GC 算法下结构差异大（如 Parallel GC 和 G1 的内存池命名、行为完全不同）。
用 jstat 实时看各代容量与使用比例
这是最常用、零侵入、适合生产环境快速确认比例的方式：
- jstat -gc <pid> 输出 EC（Eden Capacity）、EU（Eden Used）、OC（Old Capacity）、OU（Old Used）、MC（Metaspace Capacity）、MU（Metaspace Used）等列，直接用 EU/EC、OU/OC、MU/MC 就是各区域当前使用率
- jstat -gcutil <pid> 更直观：E、S0、S1、O、M 列直接显示百分比（例如 E=72.5 表示 Eden 已用 72.5%）
- 注意：S0/S1 容量通常相等，但同一时刻只有一个在用；G1 下没有固定 S0/S1，而是用“Used”和“Capacity”表示整个 Survivor 区总占用
用 jmap 查看实际划分的边界比例
它反映 JVM 当前按参数计算出的静态分区结构，适合验证配置是否生效：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
jmap -heap <pid> 输出中 “Heap Configuration” 部分明确列出：
– NewSize / MaxNewSize（新生代初始/最大大小）
– OldSize / MaxOldSize（老年代初始/最大大小）
– MetaspaceSize / MaxMetaspaceSize - 由此可算出新生代占比 = MaxNewSize / MaxHeapSize，老年代占比 = MaxOldSize / MaxHeapSize（若未显式设 -Xmn，则依赖 -XX:NewRatio 推导）
- G1 下会显示 “garbage-first heap” 及各 region 总数、已用数，此时比例需按 committed 值估算（如 G1 Heap size: 4096.0 MB, committed: 2048.0 MB）
用 ManagementFactory 编程获取精确池级占比
适合嵌入监控逻辑或告警系统，能区分具体内存池（如 PS Eden Space、Compressed Class Space）：
立即学习“Java免费学习笔记（深入）”；
- 调用 ManagementFactory.getMemoryPoolMXBeans() 遍历所有池，对每个池取 getUsage().getUsed() 和 getMax()（或 getCommitted()，当 getMax() == -1 时，如 Metaspace）
- 例如：Eden 池使用率 = used / committed（不是 max），因 Eden capacity 可能随 GC 动态变化
- 常见池名参考：
– Parallel GC：PS Eden Space、PS Survivor Space、PS Old Gen
– G1 GC：G1 Eden Space、G1 Survivor Space、G1 Old Gen、Compressed Class Space
通过 JVM 参数反推理论比例（仅作参考）
参数定义的是策略上限，不等于实际运行值，但有助于理解设计意图：
- -XX:NewRatio=2 → 理论上新生代 : 老年代 = 1 : 2（新生代占堆 1/3）
- -XX:SurvivorRatio=8 → Eden : 一个 Survivor = 8 : 1（即 Eden 占新生代 8/10，每个 Survivor 占 1/10）
- -Xmn512m → 新生代固定为 512MB，此时 NewRatio 失效；若同时设 -Xmx2g，则新生代占比为 512/2048 ≈ 25%
- G1/ZGC 下 NewRatio 无效，新生代大小由 JVM 自动弹性调节，只能靠 jstat 或 jmap 观察实时值
