不设淘汰策略的本地缓存易致OOM，必须同时配置容量上限与有效淘汰机制；大对象需按权重限制内存；监控真实淘汰量与老年代使用率，超512MB或高一致性/高加载延迟应切两级缓存。
不设淘汰策略的本地缓存，等于在堆内存里埋定时炸弹——缓存越积越多，GC 清不掉，最终触发 OOM。这不是理论风险，而是线上高频事故。关键不在“要不要淘汰”，而在于“怎么让淘汰真正生效”。
淘汰策略不是开关，是组合配置
只调用 .maximumSize(1000) 不代表淘汰就自动工作。Guava 和 Caffeine 都需同时满足两个条件：容量上限 + 淘汰触发机制。
-
Guava Cache：必须启用
maximumSize()或maximumWeight()，且不能配expireAfterWrite(Long.MAX_VALUE, ...)这类伪过期；否则 LRU 链表不触发清理，对象永久驻留 -
Caffeine：默认启用 W-TinyLFU，但若只设
maximumSize却关闭refreshAfterWrite或expireAfter，冷数据仍会堆积——尤其当 key 的 hash 冲突高、或 value 是大对象时，内存增长更隐蔽 - 共性陷阱：用
CacheBuilder.removalListener()或Caffeine.removalListener()做日志记录时，若监听器内执行耗时操作（如远程调用、同步写磁盘），会阻塞淘汰线程，导致待淘汰项积压，间接撑爆堆
大对象缓存必须加权，不能只看条目数
缓存图片、JSON 字符串、Protobuf 序列化体等大 value 时，maximumSize(1000) 毫无意义——1000 个 2MB 对象直接吃掉 2GB 堆。这时必须启用基于权重的容量控制。
- Guava：用
maximumWeight(100_000_000)+weigher((k, v) -> sizeOf(v))，按实际字节数限制总内存占用 - Caffeine：对应使用
maximumWeight()和weigher()，且其 weight 计算支持异步预估（如对 byte[] 直接取.length），开销更低 - 注意：weigher 函数不能抛异常、不能阻塞，否则整个缓存写入会被卡住；建议对未知结构先做浅层 size 估算（如字符串用
getBytes(UTF_8).length）
监控要盯住“真实淘汰量”，不是只看命中率
命中率高≠内存安全。有些服务命中率长期 99%，但 cache.stats().evictionCount() 或 cache.stats().evictionWeight() 为 0，说明淘汰根本没发生——可能是因为写入速率远低于容量上限，也可能是淘汰被抑制了。
立即学习“Java免费学习笔记（深入）”；
- 上线必埋点：定期采集
evictionCount、evictionWeight、estimatedSize三项指标，绘图观察趋势。若estimatedSize持续上涨且无下降拐点，立刻告警 - Guava 中慎用
recordStats()：它会为每个 get/put 创建 StatsCounter 实例，在高并发下本身增加 GC 压力；Caffeine 的统计是无锁且惰性聚合的，更轻量 - 配合 JVM 监控：关注老年代使用率 + Full GC 频次。若缓存淘汰量上升但老年代仍持续增长，大概率是 value 引用了外部长生命周期对象（如静态工具类、线程局部变量），形成隐式强引用链
替代方案：该用分布式缓存时别硬扛
本地缓存的本质是“用内存换速度”，但内存是单机有限资源。当业务出现以下信号，说明已超出本地缓存合理边界：
- 单实例缓存总权重稳定超过 512MB，且无法通过压缩 value 或降级策略削减
- 集群内各节点缓存内容高度重合（如全量商品信息），更新一致性靠应用层双写维护，出错概率高
- 缓存 miss 后加载耗时 > 100ms，且依赖下游 DB 或 RPC，此时本地缓存只是把延迟从下游转移到本机，还放大了内存压力
- 满足任一条件，应切到 Redis + Local Cache 两级架构：热点 key 走 Caffeine（带 refreshAfterWrite 自动刷新），冷 key 或大 value 直接查 Redis，避免本地堆失控
