Region是G1中逻辑分片而非连续内存块，大小1~32MB由JVM自动计算；每个Region可动态承担Eden、Survivor或Old角色，大对象存于Humongous Region；RSet维护跨区引用以支持低延迟回收，但占用Non-heap内存且影响写屏障性能。
Region不是连续内存块，而是逻辑分片单位
G1把堆划成固定大小的Region（默认1~32MB，由JVM自动计算），但这些Region在物理内存上完全不连续。它不按传统分代“一刀切”，而是允许每个Region动态扮演Eden、Survivor或Old角色——甚至一个Region里同时存新生代和老年代对象（比如大对象直接分配在Humongous Region）。
常见错误是以为Region = “小堆”，然后手动调-XX:G1HeapRegionSize硬凑整数倍。实际没必要：JVM会根据-Xmx自动选最合适的尺寸；强行设太小（如1MB）会导致Region数量爆炸，元数据开销反升；设太大（如32MB）又容易造成空间浪费和回收不及时。
- 用
jstat -gc <pid>看EC/SC/OC只是近似值，真实Region分布得靠-Xlog:gc+region=debug -
Humongous Region不参与常规复制算法，直接标记-清除，且至少占半个Region；大对象（>50% Region size）会触发额外扫描开销 - 混合收集（Mixed GC）只回收部分老年代
Region，优先挑垃圾比例高的——这依赖Remembered Set（RSet）维护跨区引用，RSet本身占内存约5%
混合收集（Mixed GC）的触发条件很具体
Mixed GC不是“老年代满了就来”，而是满足三个硬条件才启动：G1HeapWastePercent（默认5%）以上空间被判定为“无法回收的碎片”、并发标记完成、且老年代占用超过InitiatingOccupancyPercent（默认45%，注意是整个堆占比，不是老年代自身）。
典型误操作是调高-XX:G1MixedGCCountTarget想“多收几次”，结果反而让每次Mixed GC停顿变长——因为JVM会把原本计划分10次回收的Region压缩到5次内做完，单次处理量翻倍。
立即学习“Java免费学习笔记（深入）”；
- 监控是否进入Mixed GC：看日志里有没有
mixed gc字样，而不是只盯GC pause (G1 Evacuation Pause) -
-XX:G1MixedGCLiveThresholdPercent（默认85%）决定哪些老年代Region能进混合收集：存活对象超85%的会被跳过，避免无效搬运 - 如果Mixed GC频率异常高，先检查是不是
-XX:G1HeapWastePercent被设得太低，或者有大量中等生命周期对象卡在老年代没及时晋升
Remembered Set（RSet）是G1低延迟的关键，也是内存大户
RSet记录每个Region被哪些其他Region引用，这样回收某个Region时，不用扫描全堆找引用，只查对应RSet。但它本身要存大量卡表（Card Table）索引，且每修改一次跨Region引用，就要更新RSet——写屏障（Write Barrier）开销真实存在。
最容易被忽略的是：RSet内存占用不体现在heap usage里，而算在Non-heap memory中。用jcmd <pid> VM.native_memory summary能看到Internal项飙升，往往就是RSet吃掉了几GB。
- 减少RSet压力：避免频繁在不同
Region间传递大对象引用；用-XX:+G1UseAdaptiveIHOP让JVM动态调初始阈值，比死设InitiatingOccupancyPercent更稳 - 写屏障影响明显场景：高频更新
ConcurrentHashMap的value（尤其value是对象引用时）、大量使用Unsafe.putObject - RSet重建成本高——一次全局并发标记周期结束后，所有RSet要重算；若中途发生Full GC，RSet全部作废
G1停顿时间预测模型依赖历史数据，冷启动不准
-XX:MaxGCPauseMillis（默认200ms）不是硬性承诺，而是G1用来估算本次该回收多少Region的目标值。它靠过去几次GC的实际耗时、对象晋升速率、RSet扫描耗时等滚动加权平均来预测——所以刚启动或长时间无GC后，头几次预测大概率失准。
有人看到首次GC停顿远超设定值就慌着调小MaxGCPauseMillis，结果JVM被迫每次少收几个Region，导致老年代涨得更快，后续GC更频繁更长。
- 观察预测可靠性：加
-Xlog:gc+ergo=debug，看日志里predicted time和actual time的偏差 - 真正影响预测质量的是
-XX:G1NewSizePercent/-XX:G1MaxNewSizePercent——它们框定新生代弹性范围，JVM靠这个区间反复试错调整 - 如果应用有明显流量波峰（比如整点批量任务），建议用
-XX:G1HeapWastePercent配合-XX:G1MixedGCCountTarget做平滑缓冲，别死磕MaxGCPauseMillis
Region边界和RSet维护是G1区别于其他收集器的底层锚点，所有调优动作如果绕开这两点谈“降低停顿”，基本是在调参数幻觉。
