G1的MaxGCPauseMillis=200仅为软目标，不参与堆大小计算；适配200ms停顿的合理堆大小为4g～16g，对应Region 2M～8M，该区间源于压测与GC日志观察而非公式推导。
MaxGCPauseMillis=200 本身不参与 Region 数量或堆大小比率的“计算”，它只是 G1 的调度目标；所谓“最佳堆大小比率”，实际是通过观察 Region 分配行为反推出来的经验区间，不是公式算出来的。
Region 大小和堆大小的隐式绑定关系
G1 默认将堆划分为最多 2048 个 Region，每个 Region 大小由 -XX:G1HeapRegionSize 决定，但未显式设置时，JVM 会按 heap_size / 2048 自动取整（必须是 2 的幂次，如 1M/2M/4M…）。这意味着：
- 堆设为
4g→ Region ≈ 2M（4096MB / 2048 = 2MB） - 堆设为
8g→ Region ≈ 4M（8192MB / 2048 = 4MB） - 堆设为
16g→ Region ≈ 8M
Region 变大，单个 Young GC 需复制的对象量就可能变多，停顿时间更容易突破 200ms 目标 —— 尤其当 Eden 区跨了几十个大 Region 时。所以“堆越大，Region 越大”这个隐式关系，是影响停顿是否达标的底层杠杆。
为什么不能直接用 MaxGCPauseMillis=200 去反推堆大小？
MaxGCPauseMillis 是软目标，G1 仅用它做三件事：估算年轻代 Region 数量、决定并发线程数、调整混合回收（Mixed GC）的 Region 扫描范围。它不会倒推“该配多大堆”。真实影响停顿的关键变量是：
- 对象分配速率（每秒 new 多少 MB）
- 存活对象比例（Survivor 晋升率）
- Region 大小（间接由堆大小决定）
- 可用 GC 线程数（
-XX:ParallelGCThreads）
比如同样 MaxGCPauseMillis=200，电商下单接口（高分配、低存活）和风控模型服务（低分配、高存活）所需的堆大小和新生代占比完全不同 —— 前者需要更大新生代来吞掉短命对象，后者反而要压小新生代、早触发混合回收。
从 GC 日志里看 Region 行为，判断当前堆是否适配 200ms 目标
真正可操作的判断依据，来自 -Xlog:gc*: 输出中的这几项：
- 看
[GC pause (G1 Evacuation Pause) (young)后面的耗时是否稳定 ≤ 200ms；若频繁 > 250ms，说明 Region 太大或新生代太满 - 查
Eden regions:和Survivor regions:行 —— 若 Eden 占了 300+ 个 Region 且每个 Region 是 4M，那单次复制量就超 1.2GB，几乎不可能在 200ms 内完成 - 注意
Humongous allocations:—— 如果日志频繁出现该条目，说明有对象 > RegionSize/2，而 RegionSize 又因堆大被拉高（如 8M 堆 → 4M Region → 2M 就算大对象），这会拖慢回收并浪费空间
这时应优先调小堆（比如从 12g 改成 8g），让 Region 回到 2M～4M 安全区间，再配合 -XX:G1NewSizePercent=15 -XX:G1MaxNewSizePercent=45 锁定新生代弹性范围，比硬套“比率公式”管用得多。
容易被忽略的硬约束：Region 数量上限与堆下限
G1 要求堆至少能分出 2048 个 Region，每个最小 1MB，所以理论最小堆是 2g（2048 × 1MB）。低于这个值，G1 会降级或报错；高于 64g（2048 × 32MB），则需手动调大 -XX:G1HeapRegionSize，否则 Region 数不够用。而一旦你把堆设到 32g，Region 自动变成 16MB，此时：
- 一个
byte[8m]对象就会被塞进 Humongous 区 - Young GC 复制一个 16MB Region 的开销远高于复制多个 2MB Region
- 哪怕
MaxGCPauseMillis=200，G1 也只能“尽力而为”，实际停顿常飙到 300ms+
所以所谓“适配 200ms 的堆大小比率”，本质是把堆控制在 4g～16g 区间，让 Region 落在 2M～8M 这个 G1 实测最稳的档位 —— 不是算出来的，是压测 + 日志里看出来的。
