1. Caffeine问题随手录从原理到实战的完整避坑指南作为Java开发者我们每天都在和各种缓存框架打交道。Caffeine作为Guava Cache的现代替代品凭借其出色的性能和灵活的策略已经成为大多数Java项目的首选本地缓存方案。但在实际使用中我发现很多团队对Caffeine的理解还停留在基础API调用层面遇到性能问题或内存溢出时往往束手无策。这篇随手录整理了我近两年在生产环境使用Caffeine遇到的典型问题及其解决方案涵盖内存管理、过期策略、监控调优等实战场景。2. Caffeine核心机制解析2.1 内存模型与淘汰算法Caffeine采用Window-TinyLFU算法这是LFU和LRU的混合改进版。与Guava Cache的纯LRU不同它通过一个4-bit Count-Min Sketch频率统计器记录访问热度。我通过JMH测试对比发现在存在热点数据的场景下Caffeine的命中率比Guava Cache平均高出23%。内存结构上分为三个区域新生代Window占1%容量采用LRU策略老生代Main占99%容量采用TinyLFU策略准入过滤器基于频率的准入控制重要提示通过Caffeine.newBuilder().maximumSize(10000)设置的容量只是近似值实际占用可能超出10%-15%这是由并发数据结构特性决定的。2.2 过期策略的隐藏细节Caffeine支持四种过期方式expireAfterWrite写入后固定时间过期expireAfterAccess访问后固定时间过期expireAfter自定义过期策略refreshAfterWrite写入后延迟刷新最容易踩坑的是refreshAfterWrite与expireAfterWrite的差异refresh不会阻塞请求过期后返回旧值同时异步加载新值expire会阻塞直到新值加载完成两者混用时可能产生竞态条件// 典型错误配置示例 Caffeine.newBuilder() .refreshAfterWrite(1, TimeUnit.MINUTES) .expireAfterWrite(5, TimeUnit.MINUTES) // 这种组合可能导致数据不一致3. 生产环境常见问题实录3.1 内存溢出问题排查上周我们一个服务出现OOM最终定位到是Caffeine缓存失控增长。通过HeapDump分析发现缓存了约200万个User对象每个User平均占用2KB内存总缓存大小达到4GB远超预期根本原因是误用了弱引用// 错误用法 Caffeine.newBuilder().weakValues() // 导致频繁GC反而降低性能正确做法应该是使用maximumSize或maximumWeight明确限制容量配合Spring Cache时通过Cacheable(cacheNamesusers, size10000)声明对大数据对象采用分片缓存3.2 缓存穿透防御方案当遇到恶意请求不存在的key时传统的CacheLoader.load()会频繁触发数据源查询。我们采用的解决方案是实现NullValue对象模式设置短暂的空值缓存时间结合BloomFilter前置过滤Caffeine.newBuilder() .expireAfterWrite(10, TimeUnit.MINUTES) .build(key - { User user dao.getById(key); return user ! null ? user : NullUser.INSTANCE; // 特殊标记对象 });3.3 性能监控与调优通过Micrometer暴露的指标需要特别关注cache.loads加载次数cache.load.failure加载失败率cache.evictions淘汰数量cache.hit.ratio命中率我们发现当hit.ratio低于70%时就需要考虑调整缓存大小优化key设计检查过期时间设置4. 高级特性实战技巧4.1 权重策略的特殊应用对于大小差异显著的对象可以使用weigher函数Caffeine.newBuilder() .maximumWeight(1000000) .weigher((String key, Document doc) - doc.getSize()) .build();踩坑记录权重计算是在写入时进行的如果对象内容后续发生变化需要手动调用cache.put更新权重。4.2 异步加载优化技巧高并发场景下推荐使用AsyncLoadingCacheAsyncLoadingCacheString, User cache Caffeine.newBuilder() .refreshAfterWrite(1, TimeUnit.HOURS) .buildAsync(key - userService.getAsync(key).join()); // 使用时 cache.get(userId).thenAccept(user - {...});注意点默认使用ForkJoinPool.commonPool()建议自定义Executor控制线程数get()返回的是CompletableFuture4.3 事件监听器的正确用法通过removalListener可以监控条目移除原因.removalListener((String key, User user, RemovalCause cause) - { if (cause RemovalCause.EXPIRED) { metrics.increment(cache.expired); } })但要注意监听器执行会阻塞缓存操作耗时操作应该提交到单独线程池避免在监听器中操作原缓存实例5. 与其他组件的整合实践5.1 与Spring Cache集成要点Spring Boot自动配置的常见问题通过spring.cache.caffeine.spec配置参数注意Cacheable的sync属性对性能的影响二级缓存方案中Caffeine适合作为L1缓存推荐配置示例spring.cache.caffeine.specmaximumSize5000,expireAfterAccess30m spring.cache.typecaffeine5.2 多级缓存架构设计我们的订单服务采用三级缓存架构L1Caffeine本地100ms级L2Redis集群分布式10ms级L3数据库持久化100ms级关键同步机制通过Redis PubSub传播失效消息使用VersionedValue解决并发更新问题降级策略本地缓存过期后直接返回旧值6. 性能优化checklist根据线上经验总结的黄金法则初始容量设置initialCapacity maximumSize / 3并行度设置executor ForkJoinPool.commonPool()写入过期时间热点数据30-60分钟冷数据5-10分钟监控指标报警阈值命中率60% → 紧急告警加载失败率1% → 需要干预大对象缓存必须设置weigher最后分享一个真实案例某核心服务引入Caffeine后数据库QPS从峰值8000降低到1200平均响应时间从230ms降至45ms。关键配置是Caffeine.newBuilder() .maximumSize(20000) .expireAfterWrite(20, TimeUnit.MINUTES) .recordStats() // 必须开启统计 .build();缓存调优是个持续过程建议每季度做一次全面评估。当业务量增长50%以上时需要重新验证缓存参数的有效性。