1. 引言在构建高并发、高性能的应用程序时缓存是提升系统响应速度和降低后端负载的关键技术之一。Spring Framework 从 3.1 版本开始引入了强大的基于注解的缓存抽象允许开发者以统一的方式集成多种缓存实现而无需关心底层的缓存细节。在 Spring Boot 2.x 中官方将 Caffeine 缓存推荐为默认的缓存解决方案取代了此前常用的 Guava Cache这得益于 Caffeine 卓越的性能和丰富的特性。Caffeine 是一个基于 Java 8 的高性能缓存库其设计受到了 Guava Cache 和 ConcurrentLinkedHashMap 的启发但在此基础上进行了大量优化和创新。它提供了近乎最佳的命中率、出色的并发性能以及灵活的策略配置被广泛应用于各类互联网及企业级应用中。本文将深入剖析 Caffeine 的高性能设计原理探讨其核心算法、数据结构、并发控制及在 Spring Boot 中的集成方式帮助读者全面理解并合理使用这一强大的缓存框架。2. Caffeine 概述2.1 诞生背景Caffeine 由 Ben Manes 开发最初作为 Guava Cache 的改进版本出现。Guava Cache 虽然功能完善但在高并发场景下存在一些性能瓶颈例如使用 Segment 分段锁类似 ConcurrentHashMap 的早期实现、基于链表的 LRU 淘汰算法在高命中率下维护代价较高等。Caffeine 借鉴了 ConcurrentHashMap 的无锁设计、采用了更高效的淘汰算法 W-TinyLFU并针对现代 CPU 架构进行了优化从而在读写吞吐量、内存占用等方面全面超越 Guava Cache。2.2 主要特性自动加载支持同步或异步方式加载缓存条目。基于大小的驱逐当缓存大小超过指定阈值时基于 W-TinyLFU 算法淘汰最不常用的条目。基于时间的驱逐支持多种过期策略访问后过期、写入后过期、自定义过期时间。异步刷新在后台异步刷新缓存条目避免阻塞读请求。弱引用/软引用允许键或值使用弱引用、软引用存储便于与 GC 协作。移除监听器在条目被移除时执行自定义逻辑。统计信息提供命中率、加载时间、驱逐数量等指标便于监控。事件分发支持同步或异步的事件通知。2.3 性能优势根据官方基准测试Caffeine 在读写吞吐量、平均延迟等方面远超 Guava Cache 和 Ehcache接近 ConcurrentHashMap 的读写性能同时保持可控的内存占用。其优秀性能主要得益于W-TinyLFU 淘汰算法近似最优的访问频率统计兼具 LRU 和 LFU 的优点。无锁数据结构基于 Java 8 的 ConcurrentHashMap 改进大量使用 CAS 操作减少锁竞争。缓冲优化使用环形缓冲区RingBuffer记录事件减少写争用。时间感知优化使用系统纳秒时间戳并结合时钟缓存降低时间获取开销。3. Caffeine 核心设计原理3.1 数据结构与存储Caffeine 内部的数据存储主要依赖于ConcurrentHashMap实际上是ConcurrentHashMap的变种ConcurrentHashMapV8将键映射到一个封装了值、元数据如访问时间、写入时间、频率等的节点Node上。Node的设计是关键它不仅存储值还包含值的引用支持强引用、弱引用、软引用写入时间戳纳秒级访问时间戳用于基于时间的驱逐频率信息通过一个近似计数器维护状态标志例如是否被淘汰、是否正在加载等由于直接基于 ConcurrentHashMapCaffeine 继承了其高并发读写的特性。同时为了支持驱逐和过期Caffeine 维护了额外的数据结构访问顺序队列和写顺序队列均为双向链表但与传统 LRU 缓存不同的是Caffeine 并不严格维护全量顺序而是使用两个环形缓冲区记录最近的事件再通过异步的维护操作进行批量淘汰从而降低每次访问时的开销。3.2 驱逐策略W-TinyLFU 算法详解3.2.1 背景LRU 与 LFU 的局限LRU最近最少使用维护一个访问顺序链表每次访问将节点移到头部淘汰尾部。实现简单但无法应对偶发性的大量扫描一次性读取大量冷数据会将热点数据挤出缓存导致命中率下降。LFU最不经常使用记录每个条目的访问频率淘汰频率最低的。能更好地保留热点数据但需要维护频率计数器内存开销大且对访问模式的变化反应迟钝历史高频条目即使不再被访问也难以被淘汰。3.2.2 TinyLFU 思想TinyLFU 是一种空间高效的频率估计算法它使用一个紧凑的频率草图Frequency Sketch来近似记录每个条目的访问次数而不是精确计数。通过布隆过滤器风格的哈希和计数器数组TinyLFU 可以在极低内存开销下维护大量条目的频率信息并保证一定的误差范围。当缓存满时新条目与候选淘汰条目进行频率比较保留频率较高的一个。3.2.3 W-TinyLFU 的改进W-TinyLFU 在 TinyLFU 的基础上增加了窗口缓存Window Cache机制以应对突发流量和访问模式变化。它将缓存空间划分为两部分窗口缓存Window Cache占整个容量的 1%可配置使用 LRU 策略用于捕获近期访问的热点适应突发热数据。主缓存Main Cache占 99%使用 TinyLFU 策略记录长期热点数据。工作流程所有新条目首先进入窗口缓存LRU 区域。如果窗口缓存已满按照 LRU 规则淘汰出一个候选条目。被淘汰的候选条目进入主缓存TinyLFU 区域的“准入”环节主缓存会选择一个 Victim基于频率草图判定的最不常用条目与候选条目进行频率比较。如果候选条目的频率高于 Victim则保留候选条目将 Victim 淘汰否则淘汰候选条目。频率信息通过频率草图记录频率草图会随时间衰减使旧的频率权重降低从而适应访问模式的变化。这种设计兼顾了 LRU 对突发流量的敏感性和 LFU 对长期热点的稳定性在多种负载下均能取得接近最优的命中率。3.3 过期策略Caffeine 支持多种基于时间的过期策略可在创建缓存时指定expireAfterAccess条目在最后一次访问后经过指定时间过期。expireAfterWrite条目在创建或最后一次更新后经过指定时间过期。expireAfter自定义过期策略可以基于条目的创建时间、最后访问时间等自定义过期时间甚至实现动态过期时间如根据键值对计算不同的过期时间。为了实现过期策略每个 Node 记录了访问时间和写入时间纳秒级时间戳。Caffeine 内部通过一个维护线程或使用调度器定期扫描但更高效的方式是在读、写操作时进行惰性删除当访问一个条目时检查是否过期若过期则删除并触发加载此外还会在缓存大小达到阈值执行驱逐时顺带清理过期条目。为了提高时间戳获取的性能Caffeine 使用了System.nanoTime()相对时间不受系统时间调整影响并维护了一个时钟缓存例如每秒更新一次减少频繁调用系统调用。3.4 异步加载与刷新Caffeine 提供了同步加载和异步加载两种方式同步加载实现CacheLoader接口在缓存缺失时阻塞调用线程加载数据。异步加载实现AsyncCacheLoader接口返回CompletableFuture加载过程在异步线程池中执行不阻塞调用线程。此外Caffeine 支持定时刷新通过refreshAfterWrite指定刷新间隔。当条目超过指定时间未被更新在下一次访问时会触发异步刷新如果同时设置了expireAfterWrite刷新不会延长过期时间过期仍会驱逐。刷新机制确保缓存能定期更新避免数据过时同时不会阻塞读请求先返回旧值后台加载新值。3.5 并发控制与无锁设计Caffeine 的并发控制大量借鉴了ConcurrentHashMap的实现利用CASCompare-And-Swap操作代替锁减少线程阻塞。例如计数器的更新频率草图中的计数器使用AtomicIntegerArray或类似结构通过 CAS 更新。节点状态的变更如标记节点为淘汰状态使用AtomicReferenceFieldUpdater或VarHandle进行原子更新。环形缓冲区多个生产者读/写事件使用 CAS 入队消费者维护线程使用 CAS 出队无锁设计降低争用。尽管 Caffeine 尽力减少锁但在某些情况下仍需轻量级同步如对链表的修改但通过对操作的细粒度拆分和批量处理锁竞争被控制在极低水平。3.6 内存管理与优化Caffeine 允许配置键和值的引用类型强引用、弱引用、软引用以便与垃圾回收机制协作避免内存泄漏。弱引用键允许键被 GC 回收时自动移除条目软引用值允许在内存紧张时由 GC 回收适合作为二级缓存。此外Caffeine 内部使用对象池优化某些对象的创建如频率草图中的计数器减少 GC 压力。对时间戳等常用对象尽量使用原始类型long而非包装类节省内存。4. Caffeine 高性能实现细节4.1 近似计数与布隆过滤器TinyLFU 的核心是一个频率草图通常是一个二维数组如 4 位计数器组成的矩阵通过多个哈希函数将键映射到计数器的位置读取时取最小值作为频率估计。这种结构类似于布隆过滤器的变种可以在极小的内存占用下估计数千万键的频率误差在可接受范围内。Caffeine 采用了 4-bit 计数器最大计数 15当计数达到上限时不再增加并通过定期衰减来降低历史影响。4.2 频率草图Frequency SketchCaffeine 中的频率草图实现为FrequencySketch类内部维护一个long[]数组将 64 位划分为 16 个 4-bit 计数器。它提供了increment(key)和frequency(key)方法。草图大小根据预估的缓存大小动态计算通常是 2 的幂次方。频率的衰减通过重置操作完成当某个计数器的值超过阈值例如一半的最大值时将所有计数器的值右移 1 位除以 2实现半衰期。衰减机制使访问频率能逐渐适应新的热点模式。4.3 时间感知与时钟缓存Caffeine 高度依赖时间戳来判断过期和刷新。为了减少System.nanoTime()调用的开销Caffeine 内部维护了一个时钟缓存Ticker可以通过配置自定义。在默认实现中它直接调用System.nanoTime()但用户可以提供自己的 Ticker例如使用java.time.Clock或固定时间用于测试。此外Caffeine 会将获取到的时间戳存储在节点上在后续操作中重复使用避免重复调用。4.4 读写缓冲区与缓冲队列Caffeine 设计了两个无锁的环形缓冲区RingBuffer来记录访问事件和写事件称为MpscGrowableArrayQueue多生产者单消费者队列。当执行读操作命中时不会立即更新访问顺序避免锁开销而是将事件放入缓冲区。维护线程或下次写操作时会消费缓冲区批量更新节点的访问顺序和频率计数器。写操作如插入、更新同样会先记录事件再异步进行淘汰检查。这种批量处理显著降低了每次操作的开销提高了吞吐量。4.5 淘汰机制与维护操作淘汰操作不是实时进行的而是延迟到一定条件触发。例如当缓存大小接近上限时在写操作之后触发一次淘汰。维护线程定期执行或在每次写操作后尝试执行一次cleanUp。读操作如果发现缓冲区已满也会协助处理事件。维护操作包括消费事件缓冲区、更新频率草图、执行淘汰从窗口缓存或主缓存中移除条目、触发移除监听器等。Caffeine 使用自旋CAS的方式保证并发安全维护线程通常只有一个写操作线程会尝试充当维护者减少了锁竞争。5. Spring Boot 2.x 集成 Caffeine5.1 Spring Cache 抽象Spring Framework 提供了一个缓存抽象位于org.springframework.cache包中。核心接口是Cache和CacheManager允许开发者通过注解如Cacheable、CacheEvict声明式地使用缓存而无需关注底层实现。Spring Boot 会自动配置一个合适的CacheManager当检测到 Caffeine 依赖时会创建CaffeineCacheManager。5.2 配置 Caffeine 缓存在 Spring Boot 项目中集成 Caffeine需要添加依赖xmldependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-cache/artifactId /dependency dependency groupIdcom.github.ben-manes.caffeine/groupId artifactIdcaffeine/artifactId /dependency然后在配置文件application.yml中配置缓存属性yamlspring: cache: cache-names: users, products caffeine: spec: maximumSize500, expireAfterAccess600s或者通过编程方式配置Caffeine实例javaConfiguration public class CacheConfig { Bean public CacheManager cacheManager() { CaffeineCacheManager cacheManager new CaffeineCacheManager(users, products); cacheManager.setCaffeine(caffeineCacheBuilder()); return cacheManager; } private CaffeineObject, Object caffeineCacheBuilder() { return Caffeine.newBuilder() .initialCapacity(100) .maximumSize(500) .expireAfterAccess(10, TimeUnit.MINUTES) .recordStats(); } }5.3 使用注解在 Service 方法上使用注解javaService public class UserService { Cacheable(value users, key #userId) public User getUserById(Long userId) { // 模拟从数据库加载 return userRepository.findById(userId).orElse(null); } CacheEvict(value users, key #userId) public void evictUser(Long userId) { // 删除用户后清除缓存 } CachePut(value users, key #user.id) public User updateUser(User user) { // 更新数据库并更新缓存 return userRepository.save(user); } }5.4 编程式使用 Caffeine除了 Spring Cache 抽象你也可以直接使用 Caffeine 的原生 API获得更精细的控制javaCacheString, User cache Caffeine.newBuilder() .maximumSize(1000) .expireAfterWrite(5, TimeUnit.MINUTES) .build(); // 手动 put cache.put(key, user); // 手动 get若不存在则通过 Function 加载 User user cache.get(key, k - userRepository.findById(k).orElse(null));5.5 定制化配置与性能调优Spring Boot 集成的 Caffeine 支持大部分 Caffeine 原生配置包括initialCapacity初始容量maximumSize/maximumWeight最大条目数或权重expireAfterAccess/expireAfterWrite/expireAfterrefreshAfterWrite定时刷新weakKeys/weakValues/softValues引用类型recordStats开启统计此外可以通过CaffeineSpec解析配置字符串与配置文件中的spec对应。性能调优方面可以考虑根据业务访问模式合理设置过期时间和大小。开启统计并监控命中率调整缓存容量。若使用异步加载配置合适的线程池大小。考虑是否需要使用弱引用避免内存泄漏。6. 实战案例与性能对比6.1 案例热点数据缓存假设有一个电商系统商品详情页访问量大但商品信息变化不频繁。我们使用 Caffeine 缓存商品信息设置最大条目数为 10000过期时间为 30 分钟并开启统计。javaConfiguration public class ProductCacheConfig { Bean public CacheString, Product productCache() { return Caffeine.newBuilder() .maximumSize(10000) .expireAfterWrite(30, TimeUnit.MINUTES) .recordStats() .build(); } } Service public class ProductService { Autowired private CacheString, Product productCache; public Product getProduct(String id) { return productCache.get(id, this::loadProduct); } private Product loadProduct(String id) { // 模拟数据库查询 return productRepository.findById(id).orElse(null); } }通过 JMeter 模拟并发请求可以对比直接查询数据库和加入缓存后的性能提升。6.2 对比 Ehcache、Redis、Guava Cache特性CaffeineGuava CacheEhcacheRedis存储位置堆内内存堆内内存堆内/堆外/磁盘独立进程网络访问性能读写极高接近 ConcurrentHashMap高但锁竞争较多较高堆内磁盘较慢取决于网络延迟淘汰算法W-TinyLFU近最优LRULFU/LRU/FIFO多种LRU/LFU/随机等过期策略访问/写入后过期动态过期访问/写入后过期丰富丰富持久化无无支持支持RDB/AOF分布式本地本地可配合 Terracotta 集群分布式Spring Boot集成官方推荐支持需单独配置支持支持Redis结论Caffeine 适用于单体应用的高性能本地缓存Redis 适用于分布式缓存场景。如果应用无集群共享需求Caffeine 是性能最佳的选择。7. Caffeine 监控与统计7.1 统计指标Caffeine 内置了统计功能可以通过Cache.stats()获取CacheStats对象包含hitCount/missCount命中次数、未命中次数hitRate/missRate命中率、未命中率loadSuccessCount/loadFailureCount加载成功/失败次数totalLoadTime总加载时间evictionCount/evictionWeight驱逐次数和驱逐总权重7.2 集成 Micrometer/ActuatorSpring Boot 2.x 集成了 Micrometer可以将 Caffeine 的统计指标暴露给 Actuator。需要添加依赖xmldependency groupIdio.micrometer/groupId artifactIdmicrometer-core/artifactId /dependency然后在配置中开启javaBean public CacheString, Product productCache(MeterRegistry meterRegistry) { CacheString, Product cache Caffeine.newBuilder() .maximumSize(10000) .expireAfterWrite(30, TimeUnit.MINUTES) .recordStats() .build(); meterRegistry.gauge(product.cache.size, cache, c - c.estimatedSize()); return cache; }或直接使用CaffeineCacheManager时它默认会注册CacheMeterBinder。访问/actuator/metrics可以看到自定义指标。8. 常见问题与最佳实践8.1 缓存穿透、雪崩、击穿缓存穿透查询不存在的数据导致请求直接打到数据库。解决方案缓存空值设置短暂过期或使用布隆过滤器。缓存雪崩大量缓存同时过期导致数据库压力骤增。解决方案设置随机过期时间避免集体失效。缓存击穿热点数据过期高并发访问同时加载。解决方案使用互斥锁Caffeine 的get(key, loader)本身是原子的会阻塞其他线程直到加载完成避免了击穿。8.2 配置建议大小估算根据业务数据量和内存限制设置maximumSize或maximumWeight。过期时间根据数据更新频率设置合理的过期时间避免数据过时。统计开启生产环境建议开启recordStats()便于监控调优。异步加载对于耗时加载操作使用异步加载避免阻塞。引用类型若缓存对象占用内存大可考虑softValues让 JVM 在内存紧张时回收。8.3 注意事项Caffeine 是本地缓存不适合分布式环境下的数据一致性要求高的场景。缓存对象应不可变或至少线程安全避免并发修改导致数据错误。谨慎使用弱引用/软引用因为 GC 行为不可预测可能导致缓存过早失效。如果使用refreshAfterWrite确保刷新间隔小于过期时间否则条目会先过期刷新不起作用。9. 总结与展望Caffeine 作为 Spring Boot 2.x 官方推荐的缓存框架以其卓越的性能、灵活的策略和丰富的特性赢得了广泛认可。本文从设计原理、核心算法、并发控制、内存优化等方面深入剖析了 Caffeine 的高性能实现并介绍了在 Spring Boot 中的集成方式和最佳实践。通过 W-TinyLFU 淘汰算法、无锁数据结构、异步批量处理等创新Caffeine 在本地缓存领域达到了新的高度。