当大量缓存对象长时间驻留堆内存时，JVM 的垃圾回收会被明显拖累。问题不在于对象多，而在于这些对象大多晋升到老年代，并持续引用年轻代对象——这直接破坏了分代 GC 的核心假设。
JVM 采用分代垃圾回收策略，堆内存分为年轻代（Young Generation）和老年代（Old Generation）。这套设计基于"弱代假说"（Weak Generational Hypothesis）：
YGC 阶段，垃圾回收器从 GCRoot（全局引用、栈引用、静态变量等）开始做可达性分析。由于 YGC 只回收年轻代，JVM 在扫描上做了一个优化：
扫描中断机制：
' fill='%23FFFFFF'><rect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
old-gen scanning 的必要性
但有一种情况需要单独处理：被老年代对象引用的年轻代对象。这些对象：
为此，JVM 引入了 old-gen scanning，专门扫描老年代中可能引用年轻代对象的区域，保证这些对象不被误判为垃圾。
为了高效实现 old-gen scanning，JVM 用记忆集（Remembered Set）记录跨代引用，核心组件是 card table：
' fill='%23FFFFFF'><rect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
老年代内存占用越大、跨代引用越多，dirty card 数量也跟着涨，YGC 时间就这样被拉长了。
old-gen scanning 是 YGC 耗时高的主要原因。
这个阶段老年代被切成若干大小相等的区域（stride），每个工作线程处理其中一部分，负责扫描对应的 card 数组和被标记为 dirty 的老年代空间。
缓存数据大量堆积在老年代时：
排查 YGC 耗时问题时，用代码直接观测 Old Gen 的占用变化比单看 GC 日志更直接。JDK 通过 java.lang.management 包提供了一组 MXBean 接口，可以在运行时查询各内存池的实时状态：
import java.lang.management.*;
import java.util.List;
List<MemoryPoolMXBean> pools = ManagementFactory.getMemoryPoolMXBeans();
for (MemoryPoolMXBean pool : pools) {
MemoryUsage usage = pool.getUsage();
System.out.printf("%-30s used=%dMB / max=%dMB%n",
pool.getName(),
usage.getUsed() / 1024 / 1024,
usage.getMax() / 1024 / 1024);
}
典型输出：
PS Eden Space used=128MB / max=1024MB
PS Survivor Space used=32MB / max=128MB
PS Old Gen used=3584MB / max=4096MB
Old Gen 长期处于高水位（如 >80%）时，dirty card 数量通常也很高。配合 GarbageCollectorMXBean 一起看，可以区分是 YGC 频率问题还是单次耗时问题：
List<GarbageCollectorMXBean> gcBeans = ManagementFactory.getGarbageCollectorMXBeans();
for (GarbageCollectorMXBean gc : gcBeans) {
System.out.printf("%s: count=%d, totalTime=%dms%n",
gc.getName(), gc.getCollectionCount(), gc.getCollectionTime());
}
如果 Young GC 的 totalTime / count 持续走高但 count 没有明显增加，往往就是 old-gen scanning 的负担在增加。
控制 G1 old-gen scanning 的并行粒度，指定每个工作线程每次处理的 card 数量。
默认值 256，对应每个区域大小 = 256 × 512B = 128KB。以 4GB 堆为例，区域数量约 32,768 个，远超工作线程数。调大这个参数可以减少调度开销，降低 GC 暂停时间。
但在缓存量巨大的场景下，调整并行粒度能做的有限。dirty card 数量本身过多时，无论怎么切分任务，总扫描量不变。
JVM 启动时立即分配并初始化所有堆内存页面，避免运行时因按需分页带来的延迟抖动。适合对启动时间不敏感、对运行时稳定性要求高的应用。
禁用偏向锁，减少锁撤销时的 STW 时间，在多线程竞争激烈的场景下有用。代价是损失一些单线程性能。JDK 15 起偏向锁默认禁用（JEP 374），这个参数在高版本中已无意义。
启用 G1 垃圾回收器。
设置 G1 区域大小为 16MB。较大的区域减少内部碎片，但回收粒度也变粗。
预留 25% 的堆空间作为对象复制的 to-space，防止晋升失败触发 Full GC。
堆使用率达到 30% 时启动并发标记。提前标记可以避免临近满堆时才触发，内存压力会小很多。
指定最大 GC 暂停时间目标，G1 会尽量满足但不做硬性保证。
设置过小（如 <50ms）时，G1 会主动压缩年轻代来缩短暂停，结果是年轻代频繁填满、Minor GC 次数激增，整体吞吐反而下降。通常设在 100-200ms，再结合 GC 日志调整。
-XX:+UseCompressedOops：64 位系统下将对象指针从 64 位压缩为 32 位-XX:+UseCompressedClassPointers：压缩类指针，减少元数据内存占用缓存场景下对象数量庞大，这两个参数能压缩内存占用，顺带提升 CPU 缓存命中率。
ZGC 是低延迟场景下的可选项，最大暂停时间通常不超过 2ms，适合对响应时间要求苛刻的应用。
版本进度：
启用方式：-XX:+UseZGC
解决缓存 GC 问题的根本思路是把缓存数据从堆内移到堆外，让 GC 不再需要感知这部分数据的存在。缓存的生命周期由应用自行管理，不再委托给 JVM。
堆外内存的监控
迁移到堆外之后，MemoryMXBean.getNonHeapMemoryUsage() 看不到 Direct Buffer 的占用，它只涵盖元空间、代码缓存等 JVM 内部区域。监控堆外缓存要用 BufferPoolMXBean：
import com.sun.management.BufferPoolMXBean;
import java.lang.management.ManagementFactory;
import java.util.List;
List<BufferPoolMXBean> pools = ManagementFactory.getPlatformMXBeans(BufferPoolMXBean.class);
for (BufferPoolMXBean pool : pools) {
System.out.printf("%s: count=%d, used=%dMB, capacity=%dMB%n",
pool.getName(),
pool.getCount(),
pool.getMemoryUsed() / 1024 / 1024,
pool.getTotalCapacity() / 1024 / 1024);
}
// 典型输出：
// direct: count=1024, used=512MB, capacity=512MB
// mapped: count=0, used=0MB, capacity=0MB
堆外内存的上限由 -XX:MaxDirectMemorySize 控制，默认值等于 -Xmx。超过上限会抛出 OutOfMemoryError: Direct buffer memory，上线前要根据缓存规模显式配置这个参数，并通过 BufferPoolMXBean 持续监控。
在引入 OHC、EhCache 这类框架之前，JDK 本身就提供了操作堆外内存的能力。了解底层 API 有助于理解框架的实现原理，也能在简单场景下直接使用。
ByteBuffer.allocateDirect（JDK 1.4+）
最基础的方式是通过 ByteBuffer.allocateDirect() 申请直接内存：
// 申请 64MB 堆外内存
ByteBuffer buf = ByteBuffer.allocateDirect(64 * 1024 * 1024);
// 写入数据
buf.putInt(0, 42);
buf.putLong(4, System.currentTimeMillis());
// 读取数据
int val = buf.getInt(0);
allocateDirect 分配的内存不在 JVM 堆内，但对象头本身（DirectByteBuffer 实例）还是在堆里。GC 回收这个对象头时，会通过 Cleaner 机制触发堆外内存的释放。依赖 GC 来驱动释放有不确定性，内存密集的场景下最好显式调用：
// 显式释放（JDK 9+ 可用 sun.nio.ch.DirectBuffer）
((sun.nio.ch.DirectBuffer) buf).cleaner().clean();
ByteBuffer 的 API 是字节级操作，适合简单的二进制数据存取。用它实现一个带 LRU 淘汰、序列化、索引管理的缓存框架，工作量很大，这也是 OHC 存在的原因。
MemorySegment + Arena（JDK 21+）
JDK 21 将 Foreign Function & Memory API（FFM API）转正（JEP 454），提供了更安全的堆外内存管理方式：
import java.lang.foreign.*;
// Arena 管理内存的生命周期，try-with-resources 退出时自动释放
try (Arena arena = Arena.ofConfined()) {
// 分配 1024 字节的堆外内存
MemorySegment segment = arena.allocate(1024);
// 通过 ValueLayout 以类型安全的方式读写
segment.set(ValueLayout.JAVA_INT, 0, 100);
segment.set(ValueLayout.JAVA_LONG, 4, System.nanoTime());
int val = segment.get(ValueLayout.JAVA_INT, 0);
}
// Arena 关闭后内存立即释放，不依赖 GC
相比 ByteBuffer，MemorySegment 的生命周期更明确，Arena 关闭即释放，不存在"GC 还没跑到、内存还没还"的问题。越界访问会抛出异常，而不是静默读写错误地址。
目前 OHC、EhCache 等框架底层仍使用 ByteBuffer 或 Unsafe，FFM API 更多出现在需要与 native 库交互的场景。
OHC（Off-Heap-Cache）最初为 Apache Cassandra 开发，后来独立成为单独类库：
https://github.com/snazy/ohcOHC#stats() 获取命中率等指标Maven依赖配置：
<dependency>
<groupId>org.caffinitas.ohc</groupId>
<artifactId>ohc-core</artifactId>
<version>0.7.0</version>
</dependency>
基本使用示例：
import org.caffinitas.ohc.Eviction;
import org.caffinitas.ohc.OHCache;
import org.caffinitas.ohc.OHCacheBuilder;
OHCache<String, String> ohCache = OHCacheBuilder.<String, String>newBuilder()
.keySerializer(new StringSerializer())
.valueSerializer(new StringSerializer())
.eviction(Eviction.LRU)
.build();
ohCache.put("hello", "world");
System.out.println(ohCache.get("hello")); // world
OHC 提供两种实现：
org.caffinitas.ohc.chunked.OHCacheChunkedImpl：为每个段分配堆外内存，适合小型键值对，目前仍处于实验阶段org.caffinitas.ohc.linked.OHCacheLinkedImpl：为每个键值对单独分配堆外内存，适合中大型键值对，线上推荐使用这个两种实现都把条目缓存在堆外，堆内只保存指向堆外的地址指针。
EhCache 是老牌 Java 缓存框架，支持堆外缓存和磁盘持久化。
Maven依赖配置：
<dependency>
<groupId>org.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>3.9.0</version>
</dependency>
使用示例：
CacheManagerConfiguration<PersistentCacheManager> persistentManagerConfig = CacheManagerBuilder
.persistence(new File("/users/kinbug/Desktop", "ehcache-cache"));
PersistentCacheManager persistentCacheManager = CacheManagerBuilder.newCacheManagerBuilder()
.with(persistentManagerConfig).build(true);
// disk 第三个参数为 true 表示持久化到磁盘
ResourcePoolsBuilder resource = ResourcePoolsBuilder.newResourcePoolsBuilder()
.disk(100, MemoryUnit.MB, true);
CacheConfiguration<String, String> config = CacheConfigurationBuilder
.newCacheConfigurationBuilder(String.class, String.class, resource).build();
Cache<String, String> cache = persistentCacheManager.createCache("userInfo",
CacheConfigurationBuilder.newCacheConfigurationBuilder(config));
cache.put("orderId", "order序列化对象");
System.out.println(cache.get("orderId"));
persistentCacheManager.close(); // 确保数据 dump 到磁盘
EhCache配置选项：
ResourcePoolsBuilder.heap(10)：缓存最大条目数ResourcePoolsBuilder.newResourcePoolsBuilder().heap(10, MemoryUnit.MB)：缓存最大空间withExpiry(ExpiryPolicyBuilder.timeToIdleExpiration(Duration.ofMinutes(10)))：空闲过期时间withExpiry(ExpiryPolicyBuilder.timeToLiveExpiration(Duration.ofMinutes(10)))：存活过期时间withSizeOfMaxObjectSize(10, MemoryUnit.KB)：限制单个缓存对象大小使用堆外内存涉及磁盘存储时，建议配 SSD。SSD 的 IOPS 和带宽比 HDD 高出数量级，能明显降低 IO 延迟。哈希算法推荐 CRC32C，CPU 占用低且分布均匀。
需要排序功能时，可以把数据和索引分开存：堆外内存存完整数据，堆内只维护用于排序的关键字段（价格、数量等）。old-gen scanning 扫描的对象数量大幅减少，排序功能也不受影响。
把缓存数据迁移到堆外之后，Old Gen 占用降低，dirty card 数量随之减少，YGC 的扫描范围缩小，耗时自然下来。FGC 压力也会跟着减轻，OOM 的风险从 JVM 堆转移到了应用自行管理的堆外内存，更可控。
迁移后记得显式配置 -XX:MaxDirectMemorySize，并通过 BufferPoolMXBean 持续监控直接内存用量，避免直接内存溢出。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。