第2章 L1缓存(Local Cache)的架构边界：进程内缓存、JVM堆内/堆外、部署单元与生命周期绑定
L1缓存（Local Cache）指的是与应用程序进程绑定的、运行在同一地址空间的缓存实例。它的架构边界由三个嵌套维度决定：进程内（in-process）、JVM内存分区（堆内/堆外）以及部署单元与生命周期（Pod/容器/VM）。本章围绕这些边界阐述分层职责、数据流、选型权衡及落地验收标准。
2.1 边界分层模型
L1缓存并非单一的“内存存储”，其内部存在清晰的层次与边界。
- 层1 – 进程内缓存：缓存实例与应用程序进程共存，数据分配在进程堆或直接内存中，不跨进程共享。典型实现有
ConcurrentHashMap、Caffeine、Ehcache。 - 层2 – JVM堆内 vs 堆外：堆内缓存受GC管理，适合小数据量、高命中率场景；堆外缓存通过
DirectByteBuffer或Unsafe分配，减少GC压力，适合大数据量、长TTL数据。 - 层3 – 部署单元与生命周期绑定：L1缓存的生命周期必须与部署单元（如Kubernetes Pod、Docker容器、Java进程）一致。重启或扩缩容时缓存自动重建/回收，不可依赖跨进程持久化。
架构原则：L1缓存的边界线是“进程墙”。任何跨进程的数据一致性、持久化、分布式锁都不应放入L1缓存职责范围；这些应由L2（集中式缓存）或数据库层负责。
2.2 组件职责
| 组件 | 职责 | 典型实现 |
|---|---|---|
| 缓存管理器 | 初始化/销毁缓存实例，绑定生命周期钩子 | Caffeine CacheManager |
| 数据存储引擎 | 决定堆内/堆外存储策略，管理TTL、淘汰策略 | Ehcache OffHeapStore |
| 序列化/反序列化模块 | 堆外缓存须将对象序列化为字节数组 | Kryo / Protobuf |
| 驱逐与刷新策略 | LRU/LFU/定时刷新，控制缓存与真实数据源的一致性 | Caffeine Window-TinyLFU |
| 指标收集器 | 记录命中率、大小、GC暂停时间 | Micrometer + JVM内存MXBean |
2.3 数据流 / 控制流 / 信任链路
一次L1缓存读取请求的典型路径：
- 数据流：应用程序代码 → 缓存抽象层（Map接口） → 存储引擎（堆内/堆外） → （可选）序列化模块 → DirectByteBuffer/堆内存。
- 控制流：若缓存未命中，控制权交还调用方，由业务逻辑加载数据并回填。
- 信任链路：L1缓存被认为完全可信，但前提是 数据源变更必须主动广播失效事件。若缺少失效机制，L1缓存可能提供脏数据，破坏信任链。
风险提示：L1缓存的每个部署实例持有独立的数据副本。若部署单元数量超过100个，且没有集中的失效通知机制，将产生严重的缓存一致性问题。此时必须依赖L2缓存或消息队列进行驱逐传播。
2.4 选型权衡：堆内 vs 堆外
| 维度 | 堆内缓存 | 堆外缓存 |
|---|---|---|
| GC影响 | 强（导致GC暂停随缓存大小线性增长） | 弱（字节数组不进入GC扫描） |
| 最大容量 | 受Xmx限制，建议不超过-XX:+UseG1GC下的60% | 可单独通过-XX:MaxDirectMemorySize控制, 常用至堆大小2~3倍 |
| 序列化开销 | 无（直接存储对象引用） | 必须序列化/反序列化，增加CPU延迟（约5~15μs/次） |
| 适合场景 | 小数据量（<2GB）、高读QPS、对象复杂 | 大数据量（>2GB）、长TTL、对象结构简单或可预序列化 |
| 生命周期绑定 | 随JVM重启全部失效 | 同上，但需注意NativeMemory泄漏 |
2.5 风险点
- 内存泄漏：堆外缓存若未正确释放
DirectByteBuffer，会导致OutOfMemoryError: Direct buffer memory。 - GC与缓存抖动：堆内缓存过大时引发Full GC，导致应用暂停；堆外缓存对象序列化频繁触发Young GC。
- 部署单元扩容失效：水平扩展时每个新Pod的L1缓存为空，导致短时间内后端压力骤增（缓存雪崩）。
- 数据过期不一致：L1缓存TTL或失效通知延迟导致脏数据，尤其在多写场景。
2.6 落地步骤
- 确定缓存边界与容量：按每个Pod堆内存预算，计算L1缓存最大条目数；若超过2GB优先选用堆外。
- 选择存储引擎：堆内推荐Caffeine（SLA稳定），堆外推荐Ehcache 3 OffHeap或MapDB。
- 配置生命周期钩子：在应用启动时初始化缓存，在JVM Shutdown Hook或Spring
@PreDestroy中清理堆外内存。 - 实现失效通知接口：监听消息队列（Redis Pub/Sub或Kafka）接收数据更新事件，执行本地缓存驱逐。
- 接入指标监控：暴露
cache.hit.rate、cache.size、cache.eviction.count到Prometheus，设置告警阈值（命中率低于80%触发警告）。 - 压测验证：使用JMeter或wrk模拟峰值流量，观察GC暂停与OOM风险。
2.7 验收标准
| 验收项 | 通过标准 |
|---|---|
| 缓存命中率 | 生产环境全天命中率≥95% |
| 最坏情况GC暂停 | L1缓存堆内场景下，GC暂停≤100ms（99%分位） |
| 堆外内存泄漏 | 运行72小时后，通过jcmd <pid> VM.native_memory summary确认堆外内存稳定 |
| 失效传播延迟 | 数据源更新后，所有Pods的L1缓存最多在500ms内失效 |
| 扩容输出 | 新Pod在启动后30秒内达到90%以上缓存命中率（预加载或预热通过） |
架构边界总结：L1缓存的本质是“进程私有的、与部署单元共生死、由堆内/堆外空间划分的临时数据副本”。它的架构决策应始终围绕 进程隔离、生命周期同步、GC友好 三个核心约束展开，不越界去做分布式一致性。