Caffeine缓存最佳实践清单10个常见坑位与调优技巧【免费下载链接】caffeineA high performance caching library for Java项目地址: https://gitcode.com/gh_mirrors/ca/caffeineCaffeine 是 Java 生态中公认的高性能本地缓存库被 Spring Cache、Kafka、Solr 等大量基础设施采用。本文以清单形式梳理 10 个最常见的 Caffeine 缓存坑位与调优技巧帮助你在生产环境中正确配置 maximumSize、过期策略与命中率观测。上图展示了 Caffeine 缓存的核心设计数据按Window准入窗→ Probation试用区→ Protected保护区三段流动配合 countMinSketch 频率草图判断这个 key 值不值得缓存。理解这个结构能帮你避开下面多数坑位。一、快速上手Caffeine 缓存是什么Caffeine 提供 Guava 风格 API 的内存缓存支持自动加载、按容量淘汰、按时间过期、异步刷新、移除通知与统计。构建一个缓存只需几行配置LoadingCacheString, Graph cache Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(5)) .refreshAfterWrite(Duration.ofMinutes(1)) .build(key - createExpensiveGraph(key));配置入口都在 Caffeine.java 这个构建器类中它是全库最核心的文件。二、10 个常见坑位清单 坑位 1不设置容量上限缓存无限膨胀这是第一大坑。如果不设置maximumSize或maximumWeight缓存不会按容量淘汰只会在 GC 压力等边缘场景下被动收缩最终可能导致 OOM。✅ 正确姿势所有生产缓存都必须显式设置上限或明确知道自己为什么可以无限大例如Interner这类场景。坑位 2maximumSize 与 maximumWeight 混用冲突两者互斥设置了weigher就必须用maximumWeight二者不能同时生效。源码在 Caffeine.java#L447-L453 中会直接抛出IllegalStateException。条目大小均匀如都是 Map、String→ 用maximumSize(按条数)更省 CPU条目大小差异大如大 JSON、二进制对象→ 用maximumWeight(按字节)weigher坑位 3混淆 expireAfterWrite 与 expireAfterAccess方法计时起点适用场景expireAfterWrite最后一次写入后有 TTL 语义的数据最常用expireAfterAccess最后一次读取或写入后热数据保活型缓存expireAfterAccess会让高频访问的脏数据永不过期若数据源会更新务必改用expireAfterWrite。坑位 4softValues 被当作内存紧张自动清理银弹源码注释明确警告softValues在 JDK 8 上被大幅削弱且不建议用软引用来代替 maximumSize见 Caffeine.java#L646。推荐做法依然是maximumSize 合理的过期时间行为更可预测。坑位 5refreshAfterWrite 忘记配 executor 语义refreshAfterWrite的作用第一个发现数据过期的请求拿到旧值同时后台异步刷新避免雪崩。两个要点刷新任务运行在默认公共 ForkJoinPool 上建议用executor指定独立线程池避免拖垮计算密集型任务刷新失败时旧值仍可用除非同时配置了过期这正是它优于expireAfterWrite的地方坑位 6只信 LRU忽视频率信号Caffeine 采用TinyLFU 淘汰算法按访问频率而非单纯最近访问淘汰天然抵抗缓存污染一次性扫描大量 key 不会把热点数据冲走。其频率统计基于 countMinSketch 草图实现在 FrequencySketch.java。你无需做任何事即可享受但要理解缓存大小要给它足够学习空间过小的窗口统计会失真。Wikipedia 数据集上的命中率对比W-TinyLFu 曲线紧贴 Optimal 最优线远超 LRU坑位 7业务负载漂移时命中率骤降访问模式会随时间变化比如大促、新上线功能。Caffeine 通过自适应窗口Window 区占比在 1%~99% 间动态调整跟踪漂移核心实现在 WindowClimber.java图中蓝色命中率曲线在负载剧烈变化后迅速重新贴合绿色最优线——这是你免费获得的调优能力前提是别自己写 LRU 覆盖它。坑位 8recordStats 默认关闭命中率全靠猜Caffeine 的统计默认不采集必须显式recordStats()开启然后通过cache.stats()获取CacheStats命中率、加载耗时、驱逐数等。统计计数器实现在 ConcurrentStatsCounter.java。✅ 最佳实践把hitRate()、evictionCount()接入 Prometheus / Micrometer命中率跌破阈值如 80%时告警。坑位 9removalListener 里做慢操作移除监听器removalListener在缓存后台维护线程中同步执行。如果在这里写库、发 RPC会阻塞整个淘汰/过期维护流程导致淘汰变慢、内存峰值上升。监听器里只做轻量动作打日志、发事件重活丢给独立队列。坑位 10弱引用 weakKeys/weakValues 用于常规缓存弱引用意味着 key 只要没被强引用就会在下轮 GC 时被移除——缓存行为变得不可预测只适合外部持有引用、缓存只做去重的场景如 interning。常规业务缓存请直接用容量淘汰行为更可控见 Caffeine.java#L579 的weakKeys定义。三、性能调优速查表 ⚡调优点建议并发吞吐Caffeine 采用无锁分段读写缓冲读路径不写锁高并发下性能远超 Guava Cache无需额外分片缓存大小先开recordStats()跑一周按命中率曲线确定容量拐点而非拍脑袋数据刷新读多写少 数据可容忍短暂过期 →refreshAfterWrite替代expireAfterWrite大对象值用maximumWeightweigher按字节限容防止大 value 饿死小 value刷新线程为异步刷新指定独立executor与业务线程池隔离读写混合场景下的吞吐表现单位操作/毫秒四、扩展能力别忘了这些官方模块 JCache (JSR-107)标准规范适配器含过期策略、事件监听、JMX 管理源码见 jcache/Guava 兼容层用CaffeinatedGuava一行把 Guava Cache 换成 Caffeine实现见 CaffeinatedGuava.javaSpring Cache社区集成配置spring.cache.typecaffeine即可Simulator用真实数据集仿真命中率评估缓存大小决策见 simulator/五、总结一张清单带走 ✅ 必设maximumSize或maximumWeight✅ 按数据类型选expireAfterWrite还是expireAfterAccess✅ 用refreshAfterWrite 独立executor防雪崩✅ 开recordStats()并接入监控✅ 移除监听器保持轻量✅ 别用 softValues/weakKeys 替代容量淘汰✅ 相信 TinyLFU别手写 LRU 覆盖✅ 条目大小不一时用 weigher 按字节限容✅ 用 Simulator 验证容量决策✅ 迁移 Guava Cache 时优先用官方兼容层Caffeine 的设计目标是近乎最优命中率 接近无锁的吞吐把上面的坑位避开你就能免费拿到论文级缓存算法的生产收益。【免费下载链接】caffeineA high performance caching library for Java项目地址: https://gitcode.com/gh_mirrors/ca/caffeine创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考