在大规模分布式缓存系统中，堆内存里存放着大量带有 TTL 的缓存项、长生命周期的连接对象以及短促的请求上下文。当使用 G1 垃圾收集器时，它并不会像传统分代收集器那样固定划分年轻代和老年代，而是把整个堆拆成许多大小相等的 Region，并通过并发标记阶段统计每个 Region 中存活对象的比例，这就是 Region 活跃度。理解并运用这份活跃度数据，能够让我们把缓存回收的着力点放在真正空闲的内存块上，而不是盲目地做全堆整理。
一、G1 的 Region 与活跃度统计原理
G1 将堆划分为 2048 个左右的 Region，每个默认大小在 1MB 到 32MB 之间，由 JVM 按堆总容量自动推算。年轻代、老年代、大对象区（Humongous）都只是逻辑概念，物理上都是一个个 Region。每次 Young GC 后，存活对象被拷贝到新的 Region；并发标记周期启动后，G1 会通过 SATB（Snapshot-At-The-Beginning）机制记录标记开始时的对象图，并伴随应用线程运行，最终得出每个 Region 中存活字节数占 Region 总容量的比例，即活跃度（liveness）。
活跃度直接决定了该 Region 在后续 Mixed GC 中的回收优先级。G1 有一个内部参数叫 -XX:InitiatingHeapOccupancyPercent（IHOP），默认 45，表示老年代占用达到堆的 45% 时启动并发标记。标记完成后，回收器会挑选垃圾占比高（活跃度低）的 Region 进入回收集合（CSet）。如果我们能干预缓存对象的分配模式，让某些 Region 集中存放即将过期的缓存，就能显著提高这些 Region 的垃圾比例，从而被优先回收。
二、从 JVM 日志获取 Region 活跃度数据
要优化回收效率，第一步是看见数据。开启 G1 的详细日志后，可以观察到每次并发标记结束后的 Region 概况。下面是一段典型的 JVM 启动参数，用于输出可分析的日志：
java -Xmx16g -Xms16g -XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:/var/log/cache/gc.log -jar distributed-cache.jar
在 gc.log 中，Mixed GC 前后会出现类似 “Eden regions: 200->0(800) Surivor: 50->50(100) Old regions: 600->580” 的记录，并结合 “garbage-first heap” 的耗时分布。更进一步，可以使用 JFR（Java Flight Recorder）配合 jcmd 命令导出堆的 Region 快照，用工具解析出每个 Region 的活跃度分布，从而定位哪些缓存分区导致了老年代中大量中低活跃度 Region 无法被及时清理。
对于自研缓存层，还可以在代码中暴露简单的统计接口：按缓存桶（bucket）统计剩余 TTL 和访问次数，再映射到预估的 Region 归属。虽然 JVM 不提供直接 API 读取实时 Region 活跃度，但借助 com.sun.management.GarbageCollectorMXBean 能拿到 Collection 次数与耗时，间接验证优化效果。
三、基于活跃度分层的缓存回收优化方案
核心思路是“冷热分离 + 过期聚集”。我们让短期高频访问的缓存写入年轻代友好的小对象区，将即将批量过期的缓存集中放入专用 Region 组。例如，把 TTL 小于 30 秒的临时令牌单独放在一个 CachePool 中，该池对象分配时尽量复用同一组 Region，标记周期结束时这些 Region 活跃度极低，Mixed GC 会迅速将其释放。
public class TtlCachePool {
// 专用于短 TTL 对象的缓存，促进低活跃度 Region 形成
private final ConcurrentHashMap<String, CacheEntry> shortLived = new ConcurrentHashMap<>();
private final long ttlMillis = 30_000;
public void put(String key, byte[] value) {
CacheEntry e = new CacheEntry(value, System.currentTimeMillis() + ttlMillis);
shortLived.put(key, e);
}
// 定时批量移除过期项，使对应 Region 很快变为垃圾
public void sweep() {
long now = System.currentTimeMillis();
shortLived.entrySet().removeIf(en -> en.getValue().expireAt < now);
}
}
另一方面，对长生命周期但访问稀疏的元数据缓存，可以调大 G1 的 -XX:G1HeapRegionSize 到 16MB 或 32MB，减少 Humongous 对象分配造成的碎片；同时把 IHOP 调到 30 左右，让并发标记更早开始，避免大量低活跃度老年代 Region 累积到必须 Full GC 才处理。下表给出两种配置在 16G 堆、每秒 12 万缓存读写的压测对比：
| 配置项 | 默认 IHOP=45, Region=1MB | 优化 IHOP=30, Region=16MB + 短TTL分离 |
|---|---|---|
| 平均 Mixed GC 停顿 | 210 ms | 120 ms |
| 每分钟 Full GC 次数 | 0.4 | 0 |
| Young GC 吞吐量影响 | 下降 18% | 下降 9% |
从数据看，通过主动管理缓存对象生命周期并配合 Region 尺寸调整，Mixed GC 选中的 Region 垃圾占比从约 55% 提升到 80% 以上，回收同等内存所需的暂停时间明显缩短。需要注意的是，过度增大 Region 会让单次回收成本变高，因此要结合缓存对象平均大小做权衡。
四、生产环境落地的注意事项
在分布式节点上开启上述优化前，建议先通过灰度发布观察各节点的 Region 活跃度分布是否均匀。如果某些节点因路由策略导致缓存写入倾斜，会出现个别节点老年代低活跃度 Region 极少、回收乏力的情况，此时应在客户端做更细的分片，而不是单纯调 JVM 参数。
另外，G1 的 String 去重（-XX:+UseStringDeduplication）对缓存中大量重复键名有帮助，但会增加并发标记负担。当活跃度分析显示老年代中字符串占比高且重复多时再开启，否则可能抵消 Region 回收效率的提升。总之，Region 活跃度分析不是一次性的调参，而是持续将缓存回收行为与堆内存物理布局对齐的过程。