-xx:g1heapregionsize 是 jvm 启动时静态设定的参数，不可运行时动态调整；它决定 region 大小（1mb～32mb、2 的幂），影响 rset 开销、humongous 对象分配及 gc 精度与停顿。
-XX:G1HeapRegionSize 并不能动态调整 G1 的 Region 大小，它是一个 JVM 启动时的静态参数，只在 JVM 初始化堆时生效一次。
Region 大小在启动时就固定了
G1 堆被划分为若干个大小相等的 Region（区域），每个 Region 的大小由 -XX:G1HeapRegionSize 指定。但这个值必须是 2 的幂（如 1MB、2MB、4MB），且范围在 1MB 到 32MB 之间。JVM 在启动时根据堆总大小和该参数计算出 Region 总数，并从此固定——运行过程中不会因内存压力、分配行为或 GC 次数而自动改变 Region 大小。
- 例如：设置
-XX:G1HeapRegionSize=2M，JVM 就会把整个堆（比如 4GB）划分成 2048 个 2MB 的 Region，后续所有 GC 操作都基于这个尺寸组织记忆集（Remembered Set）、并发标记和混合回收。 - 如果未显式设置，JVM 会根据初始堆大小（-Xms）自动推导一个“合理”的 Region 大小（通常为 1MB～4MB），但仍是静态决定的。
为什么不能动态调整？
G1 的核心数据结构（如 Remembered Set、Card Table、Region 状态位图）都依赖 Region 的固定边界和统一尺寸。若运行中改变 Region 大小，会导致：
- Remembered Set 的索引映射失效（每个 Region 对应独立的 RSet）
- 已分配对象的地址归属关系混乱（对象跨 Region 或落入错误 Region）
- 并发标记与 Evacuation 过程无法安全进行（移动对象时需精确知道目标 Region 容量）
所以 JVM 设计上禁止运行时变更 Region 结构，这是 G1 可预测性与并发安全的前提。
如何选择合适的 Region 大小？
虽然不能动态调，但选对初始值很关键。Region 太小 → RSet 开销大、GC 线程管理碎片多；太大 → 无法精细回收、Mixed GC 易暂停过长。
- 大对象（≥ 50% Region 大小）会被直接分配到 Humongous Region，若 Region 太小，容易触发大量 Humongous 分配，引发频繁 Full GC 或内存浪费。
- 建议先用默认值启动，再通过
-Xlog:gc*,gc+heap=debug观察日志中的 “Heap region size” 和 “Humongous allocation” 频次，再针对性调整。 - 典型场景参考：堆 ≤ 4GB → 1MB；4–16GB → 2MB；≥ 16GB 且有较多中等对象 → 尝试 4MB。
替代“动态调整”的实际手段
虽然 Region 大小不可变，但可通过其他方式间接影响回收行为：
- 用 -XX:G1NewSizePercent / -XX:G1MaxNewSizePercent 控制年轻代占比，从而影响 Eden 区 Region 数量（不改变单个 Region 大小）
- 用 -XX:G1MixedGCCountTarget 和 -XX:G1OldCSetRegionThresholdPercent 调整 Mixed GC 回收老年代 Region 的节奏和数量
- 结合 -XX:MaxGCPauseMillis 让 G1 自适应选择每次回收多少 Region（仍基于固定大小）
这些参数作用于 Region 的“使用策略”，而非其物理结构。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
