Caffeine缓存热点数据需聚焦三类：访问频次高、变更频率低、允许短暂不一致的数据，如字典类、用户基础信息、计算结果；须合理配置大小限制、分场景设置过期策略、启用统计监控，并通过“查缓存→查DB→回填缓存→变更时失效key”闭环管理，结合Redis构建两级缓存防雪崩。
直接用 Caffeine 缓存热点数据，能显著减少数据库查询次数——关键不是“要不要缓存”，而是“缓存什么、怎么缓存、怎么更新”。
明确哪些数据适合缓存
不是所有数据都该放进 Caffeine。重点盯住三类：访问频次高、变更频率低、允许短暂不一致。
- 字典类数据：省市区列表、订单状态枚举、商品分类树——这类数据上线后几乎不变，缓存 24 小时甚至更久都安全；
- 用户基础信息：昵称、头像 URL、会员等级——单个用户读多写少，按 userId 缓存，过期时间设为 10~30 分钟较稳妥；
- 计算结果：某商品的满减规则组合、某个报表的聚合结果——耗时操作执行一次，结果缓存起来，避免重复计算。
避开实时性要求高的场景，比如账户余额、库存扣减中的“剩余数”，这类必须走数据库或分布式锁+Redis，不能依赖本地缓存。
配置合理的缓存策略
Caffeine 不是“开箱即用就高效”，得根据业务调参：
立即学习“Java免费学习笔记（深入）”；
-
大小限制必须设：用
.maximumSize(1000)防止内存无限增长，尤其在缓存 key 是动态生成（如带参数的接口路径）时； -
过期策略要分场景：静态字典用
expireAfterWrite(24, HOURS)；用户信息建议expireAfterAccess(5, MINUTES)，兼顾新鲜度与复用率； -
启用统计功能：加一句
.recordStats()，后续通过cache.stats().hitRate()观察命中率——长期低于 85%，说明缓存没起效，得查是不是 key 设计不合理或过期太短。
对接数据库时做“穿透+回填”闭环
缓存只是中间层，不能脱离数据源独立存在。标准流程是：
- 先查 Caffeine，命中则直接返回；
- 未命中，再查数据库；
- 查到后，立即写入缓存（注意设置合理过期），下次请求就走内存了；
- 数据变更时（如后台修改商品价格），同步 失效对应 key（
cache.invalidate(key)），而不是试图更新缓存值——避免脏数据和并发写乱序。
不推荐“更新数据库同时更新缓存”，因为失败场景难兜底；“先删缓存，再改 DB”是更简单可靠的模式。
结合 Redis 构建两级缓存防雪崩
单靠 Caffeine 有局限：进程重启即丢失、集群中各节点缓存不一致。所以生产环境通常搭配 Redis：
- 第一级：Caffeine（毫秒级响应，扛住 90% 热点请求）；
- 第二级：Redis（百毫秒级，承担剩余请求 + 跨节点共享）；
- 访问顺序：Caffeine → Redis → DB；写入时，DB 成功后主动清掉两级缓存 key。
这样既保留本地缓存的极致性能，又通过 Redis 保证基本一致性，还能避免 DB 瞬间被打穿。
