Caffeine针对ConcurrentHashMap做了哪些改进？Window TinyLFU算法详解

原创 已于 2025-11-04 10:51:03 修改 · 1k 阅读 · 9 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#算法 #数据结构 #后端 #java #缓存

于 2025-11-04 10:50:44 首次发布

Caffeine针对ConcurrentHashMap进行的改进

优化角度

  1. 缓冲化：使用写入和访问记录缓冲区，将零散的、并发的操作变为批量的、顺序的操作。

  2. 异步化：将维护任务从主读写路径中剥离，交给后台线程处理

  3. 处置化：将经常变化的状态（访问顺序、访问频率）从主存储结构剥离（CHM 的 Value），使用更高效的专业数据结构（时间轮、Count-Min Sketch）管理

  4. 无锁化：在核心读路径上，使用volatile读和无锁操作，确保性能不受影响

一、写缓冲区

作用：使用写入和访问记录缓冲区，将零散的、并发的操作变为批量的、顺序的操作。

  1. 当有写入操作（put、remove）发生时，Caffeine 并不立即直接操作底层的 CHM。

  2. 而是先将这个操作（以及相关的元数据变更，如访问记录）追加到一个无锁的多生产者单消费者队列中。

  3. 由一个独立的后台线程（或在你调用 get 时顺带处理）批量地从缓冲区中取出多个操作，再批量地应用到真正的 CHM 上。

好处：

  • 减少锁竞争：将高并发下大量零散的、需要竞争锁的写操作，合并成少量的、批量的写操作，极大地降低了 CHM 的锁粒度。

  • 提升响应速度：写入线程只需将操作放入缓冲区即可返回，无需等待真正的 CHM 操作完成，写入延迟更低。

二、锁策略

Caffeine 极力避免在常见的读路径上进行任何需要锁的操作。

  • Guava Cache 的对比：Guava Cache 为了实现 LRU，每次 get 访问都需要获取锁来操作访问队列（移动链表节点）。

  • Caffeine 的做法：

    • 无锁的读：基础的 get 操作就是 CHM 的 get，这本身几乎是无锁的（或使用非常高效的 volatile 读和 CAS）。

    • 延迟记录访问：当一个条目被访问时，Caffeine 不会立即去更新一个复杂的顺序链表。它可能只是：

      1. 在条目本身记录一个 volatile 的时间戳。

      2. 或者，将这次访问事件异步地记录到缓冲区（类似于写缓冲区），再由后台线程统一处理排序逻辑。

三、解耦排序与存储

针对过期淘汰优化

  • 传统做法（Guava）：维护一个按访问时间或写入时间排序的双向链表。插入、删除、移动节点都需要操作链表，意味着需要加锁。

  • Caffeine 的优化：使用 时间轮 算法来管理过期。

    • 工作原理：时间轮是一个环形的数组，每个槽代表一个时间范围（比如 1 秒）。所有在同一秒内过期的条目都被放在同一个槽对应的链表中。

    • 如何解耦：

      1. 当一个条目被存入 CHM 时，会根据它的过期时间计算出它应该在时间轮的哪个槽里。

      2. 只需要将这个条目引用到那个槽的链表里即可。这个操作很快，且通常每个槽各自持有独立的锁，竞争非常少。

      3. 处理过期时，一个后台线程只需转动时间轮，取出当前槽对应的链表，批量地、异步地从 CHM 中删除这些条目。

    • 好处：

      • 淘汰操作异步化：过期清理不再阻塞用户的读写请求。

      • 高性能：插入和删除过期条目的开销是常数级的 O(1)，而维护一个全局排序链表的代价是 O(n)。

四、频率统计

Count-Min Sketch数据结构，一个全局的、大小固定的二维数组，用于近似统计所有key的访问频率

  • 如何解耦：

    1. 每次访问时，get 方法在从 CHM 中取出值后，会异步地向 Count-Min Sketch 报告一次访问

    2. Count-Min Sketch 的更新是使用哈希计算定位后直接累加，冲突概率低，速度极快。

    3. 当需要淘汰时（大小已满），决策引擎会咨询 Count-Min Sketch 来比较两个条目的频率，而无需触动 CHM 的主存储结构。

  • 好处：

    • 读操作与频率统计解耦：get 操作的核心路径几乎不受影响。

    • 极小且固定的内存开销：无论缓存多少数据，频率统计结构的大小都不变。

Window TinyLFU算法

Caffeine将缓存区划分为两个区域：Window Cache 和 Main Cache

  • Window Cache 是一个标准的LRU缓存，只占整个缓存内存空间大小的1%

  • Main Cache 则是一个 SLRU (Segmented LRU) ，占整个缓存内存空间大小的 99% ，是缓存的主要区域。里面进一步被划分成两个区域：Probation (试用) Cache 观察区（20%）和 Protected (保护) Cache 保护区（80%）。

  • 三个区域中的缓存都可以被访问到

  • 算法中每个缓存项由都两部分组成：数据本身、访问次数

算法流程

  • 新增缓存数据首先写入 Window Cache 区域。当 Window Cache 空间满时，LRU 算法发挥作用，最久未被访问的缓存项会被移出 Window Cache 。针对这个缓存项，分为两种情况：

    1. 如果试用缓存未满，则直接写入到试用缓存区中

    2. 试用缓存已满，则进入TinyLFU过滤器，与保护缓存区移出的缓存项比较，根据TinyLFU算法确定是否写入保护缓存区

  • 试用缓存区中的缓存项的访问频率达到一定程度后，就会晋升到保护缓存区中，如果保护缓存区也满了，根据 LRU 算法，最久未被访问的缓存项会被移出保护缓存区，降级成为缓存项，进入到TinyLFU过滤器中，与Window Cache移出的缓存项作比较，根据TinyLFU算法确定该缓存项是淘汰还是降级到试用缓存区中

  • TinyLFU过滤器：汇聚了三个区域中最久未被访问的缓存项，在过滤器中竞争：

    • 如果Window Cache和保护缓存区中的缓存项访问频率 > 试用缓存区中的缓存项，直接淘汰试用缓存区中的缓存项

    • 如果Window Cache和保护缓存区中的缓存项访问频率 ≤ 试用缓存区中的缓存项，分两种情况：

      1. 如果Window Cache和保护缓存区中的缓存项的访问频率 ＜ 5，则淘汰Window Cache和保护缓存区中的缓存项

      2. 否则这三种数据项随机淘汰一个

    • 保留的缓存数据项被写入到试用缓存区中

Count-Min Sketch

W-TinyLFU 算法使用 Count-Min Sketch 算法存储访问频率，极大地节省了空间，底层结构是一个二维数组，通过多个Hash函数计算得到缓存项在数组中的位置，当要添加数据时，在对应位置上的记录+1，判断频率时则取对应位置中的最小值作为频率次数

Google guava第一讲：guava缓存实战/使用场景/缓存清理/最佳实践/caffeine实战
Jet_qi的博客
04-15 5804
Guava缓存实战及使用场景 摘要：本文先介绍了Guava Cache囊括的基本使用方法，然后结合体系类图和LocalCache的数据结构对典型的几个方法源码进行流程分析。重点 缓存的命中率，缓存的失效时间，缓存的OOM，缓存的统计数据等。 文章目录Guava缓存实战及使用场景1 为什么使用本地缓存1.1 适用场景2 如何使用Guava缓存(缓存容量/超时时间/移除监听器/缓存加载器)2.1 ......
Caffeine的Window TinyLfu算法分析
snail-jie的博客
06-17 1969
概括 通过put操作将数据放入data属性中（ConcurrentHashMap） 创建AddTask任务，放入(offer)写缓存：writeBuffer 从writeBuffer中获取任务，并执行其run方法,追加记录频率：frequencySketch().increment(key) 往window区写入数据 W-TinyLFU 整体设计 本部分参考了泥瓦匠BYSocket的文章，文章链接：https://jishuin.proginn.com/p/763bfbd358a0 判断一个缓存的好坏
Caffeine 详解：Java 本地缓存的性能之王
csdn_tom_168的博客
07-04 1122
Caffeine是Google开发的高性能Java本地缓存库，采用W-TinyLFU算法优化缓存命中率，支持异步加载、多种过期策略和监听器机制。其核心优势在于内存级的访问延迟（纳秒级）和无锁设计，适用于单节点高频数据访问场景，如会话缓存、热点配置等。相比Guava Cache，Caffeine提供更智能的缓存淘汰策略和丰富的扩展功能；相比Redis，它更适合本地小规模缓存需求。通过灵活的配置选项和统计监控，Caffeine成为Java生态中最强大的本地缓存解决方案之一。
详解本地缓存之王 Caffeine
zwrlj527的专栏
12-30 1946
概要 Caffeine[1]是一个高性能，高命中率，低内存占用，near optimal 的本地缓存，简单来说它是 Guava Cache 的优化加强版，有些文章把 Caffeine 称为“新一代的缓存”、“现代缓存之王”。 本文将重点讲解 Caffeine 的高性能设计，以及对应部分的源码分析。 与 Guava Cache 比较 如果你对 Guava Cache 还不理解的话，可以点击这里[2]来看一下我之前写过关于 Guava Cache 的文章。 大家都知道，Spring5 即将放弃掉 Gu
本地缓存Caffeine详解（含与Spring Cache集成）
路漫漫其修远兮，吾将上下而求索
06-27 3223
本文深入解析Caffeine缓存库的核心原理与实践应用。作为Java生态中高性能本地缓存的现代解决方案，Caffeine采用优化的ConcurrentHashMap存储结构，结合Window-TinyLFU淘汰算法和精妙的并发控制机制，实现高达98%的命中率。文章通过实战案例演示了基础用法，详细讲解容量控制、过期策略等配置项，并展示与SpringCache的整合方案。针对生产环境，提出防范缓存穿透/雪崩等问题的建议，同时预告了Caffeine与Redis多级缓存架构的实现思路。全文兼具理论深度与实践指
万字详解本地缓存之王 Caffeine 的高性能设计之道！
十指波课堂的博客
12-16 1048
概要Caffeine是一个高性能，高命中率，低内存占用，near optimal 的本地缓存，简单来说它是Guava Cache的优化加强版，有些文章把Caffeine称为“新一代的缓存”、“现代缓存之王”。本文将重点讲解Caffeine的高性能设计，以及对应部分的源码分析。与Guava Cache比较如果你对Guava Cache还不理解的话，可以点击这里来看一下我之前写过关于Guava Cac...
Guava 与 Caffeine 本地缓存系统详解
HGX-DJK
08-05 462
Caffeine 是 Guava Cache 的接班人，由 Ben Manes 编写，其目标是提供更高性能、更多特性、更现代化的缓存实现。Guava：适合一般场景，轻量级需求、快速接入。Caffeine：适合高并发、对性能有严格要求的项目，是目前 Java 生态最强大的本地缓存方案。
本地缓存Caffeine从入门到原理剖析
m0_74229735的博客
12-05 1644
自定义的缓存状态收集器的作用：每当缓存有操作发生时，不管是查询，加载，存入，都会使得缓存的某些状态指标发生改变，哪些状态指标发生了改变，就会自动触发收集器中对应的方法执行，如果我们在方法中自定义的代码是收集代码，比如将指标数值发送到 kafka，那么其它程序从kafka读取到数值，再进行分析与可视化展示，就能实现对缓存的实时监控了。收集器接口为 StatsCounter ，我们只需实现这个接口的所有抽象方法即可。下面举例说明。@Override。
缓存之美：万文详解 Caffeine 实现原理（上）
方圆 Blog
01-21 1344
文章将采用“总-分-总”的结构对配置固定大小元素驱逐策略的 Caffeine 缓存进行介绍，首先会讲解它的实现原理，在大家对它有一个概念之后再深入具体源码的细节之中，理解它的设计理念
万字详解本地缓存之王 Caffeine
码农code之路
12-28 523
来自：r6d.cn/UXR4概要Caffeine[1]是一个高性能，高命中率，低内存占用，near optimal 的本地缓存，简单来说它是 Guava Cache 的优化加强版，有些文...
caffeine 支持哪些结构
09-27
另外，引用[4]提到Caffeine通过Window-TinyLFU算法、分段锁与无锁设计等实现高性能。 因此，Caffeine支持的结构可以从以下几个维度来看： 1. **基础存储结构**：ConcurrentHashMap，这是Caffeine存储缓存项的核心...
Caffeine本地缓存详解：高性能Java缓存库实战指南
例如，W-TinyLFU算法融合了TinyLFU的频率估算和Window机制，既能识别热点数据，又能及时捕获新近活跃项，避免传统LFU对突发流量反应迟钝的问题。 综上所述，Caffeine不仅是技术上的突破，更是工程实践中的典范。它...
【软考】算法
最新发布
weixin_49929829的博客
11-23 64
分治、动态规划、贪心、回溯算法基本思想
2025年全国青少年信息素养大赛复赛真题（算法创意实践挑战赛C++初中组试卷1：带解析）（7月6日试卷）
王老师青少年编程
11-21 644
2025年全国青少年信息素养大赛复赛真题（算法创意实践挑战赛C++初中组试卷1：带解析）（7月6日试卷）
力扣每日一题：可被三整除的最大和
yyssas的博客
11-23 114
会发现：假如现在对于前i个元素，可以被三除余j，则对于第i个元素x，如果取了，那么要在前i-1个元素中，找到被三除余j-x。如果不取，就是在前i-1个元素中找到被三除余j。然后要考虑的是边界条件，就是当i<0的情况，此时对于前-1个元素，无疑只能找除3余0的，余1和余2均是不存在，因此设定余1余2都是负无穷，这样就不会取到了。最开始考虑的是用01背包问题，对每个元素动态取舍，最后找到最大值。但感觉用数组一直存，可能会爆炸，因为和可能会很大。因此选择动态递归的方式，找到取前i个和取前i+1个元素的关系。
传统NLP算法
记录成长‌，知识沉淀，连接同行‌
11-19 733
传统NLP算法与当前大模型的对比分析 传统NLP算法主要基于规则和统计模型（如HMM、CRF、SVM），依赖人工特征工程和领域知识，适合特定任务但泛化能力有限。其优势在于可解释性强、计算资源需求低。典型应用包括分词、命名实体识别和文本分类等。 现代大模型（如Transformer架构LLM）采用预训练-微调范式，通过海量数据自动学习语言表示，具备强大的生成能力和跨任务迁移性。它们能处理复杂任务如对话生成和多语言翻译，但需巨额计算资源。 二者存在技术演进关系：大模型继承了传统NLP的核心思想，但通过深度学习实
算法沉淀第十二天（牛客练习赛146）
lingran__的博客
11-22 722
本文分享了牛客练习赛146的三道算法题解：1.《合格的机器》通过分析代币奇偶性，得出最优解是尽量使机器代币数为偶数，当总代币数≥2n时最多n-1台合格；2.《小灰灰的火焰星球2》通过排序施法顺序和预处理价值数组，实现高效计算最大收益；3.《盲目自大的小灰灰》通过计算得分区间，判断查询分数是否可能达到。每道题都包含题意分析、逻辑梳理和AC代码实现，适合算法学习者参考。
【元启发算法】模拟退火（SA）：在温度起伏中，寻找最优解的诗意算法
Harrytutu_ZuiYue的博客
11-21 346
自然从不急于求成，金属在冷热交替中趋于稳定，算法亦在温度起落中逼近真理。” 寒冬里调温的空调、背包旅行时规划路线、手机 APP 优化资源分配 —— 生活中处处藏着 “寻找最优解” 的难题。有些问题看似简单，却因可选方案过多，让我们陷入 “局部最优” 的困境：就像在山谷中徒步，误以为眼前的山峰就是最高点，却不知翻过一座小山后，还有更广阔的天地。
D3QN+PER机制算法
2301_79815102的博客
11-22 631
Dueling Network是一种深度强化学习网络架构，将Q值分解为状态价值函数V(s)和优势函数A(s,a)。V(s)评估状态本身的好坏（标量输出），A(s,a)衡量各动作的相对优势（向量输出）。通过共享编码器和两个独立分支分别学习V(s)和A(s,a)，最后聚合层采用减去优势均值的约束方式计算最终Q值。这种架构能更高效地学习状态价值，提升策略表现，常与Double DQN和PER机制结合使用（如D3QN+PER算法）。
spring boot caffeine redis能同时使用吗？
07-08
<think>我们正在讨论Spring Boot中同时集成Caffeine和Redis缓存的问题。根据引用内容，我们可以确认这是可行的，并且通常用于构建两级缓存（本地缓存+分布式缓存）系统。 引用[1]提到“Spring Boot 使用多级缓存 {Caffeine+Redis}”，并给出了快速入门的示例。 引用[2]解释了在分布式环境下使用Redis的发布/订阅功能来同步各个节点的缓存，解决一致性问题。 引用[3]则展示了具体的配置代码，其中通过条件注解@ConditionalOnProperty来控制本地缓存（Caffeine）的开关。 因此，我们可以分步骤解释如何在Spring Boot中同时集成Caffeine和Redis： 步骤1：添加Maven依赖 需要同时添加spring-boot-starter-cache（用于支持Spring缓存抽象）、spring-boot-starter-data-redis（用于Redis）和caffeine（用于本地缓存）的依赖。 步骤2：配置缓存 在application.properties或application.yml中配置Redis和Caffeine的相关属性。 步骤3：启用缓存 在启动类上添加@EnableCaching注解。 步骤4：配置多级缓存 如引用[3]所示，可以创建配置类来定义Redis缓存和Caffeine缓存，并且通过条件注解来控制Caffeine缓存的启用。 步骤5：使用缓存 在业务代码中，可以使用@Cacheable等注解来使用缓存。同时，为了支持多级缓存，可能需要自定义缓存管理器，将Caffeine作为一级缓存，Redis作为二级缓存。 引用[2]提到，为了解决分布式环境下本地缓存不一致的问题，可以使用Redis的发布/订阅功能来同步各个节点的缓存。 下面是一个简化的示例代码，展示如何配置多级缓存： ```java @Configuration @EnableCaching public class CacheConfig { // 配置Redis连接工厂 @Bean public RedisConnectionFactory redisConnectionFactory() { return new LettuceConnectionFactory(); } // 配置RedisTemplate @Bean public RedisTemplate<String, Object> redisTemplate() { RedisTemplate<String, Object> template = new RedisTemplate<>(); template.setConnectionFactory(redisConnectionFactory()); template.setKeySerializer(new StringRedisSerializer()); template.setValueSerializer(new GenericJackson2JsonRedisSerializer()); return template; } // 配置Redis缓存管理器 @Bean public RedisCacheManager redisCacheManager(RedisTemplate<String, Object> redisTemplate) { RedisCacheManager cacheManager = new RedisCacheManager(redisTemplate); cacheManager.setTransactionAware(true); cacheManager.setLoadRemoteCachesOnStartup(true); cacheManager.setUsePrefix(true); return cacheManager; } // 配置Caffeine缓存管理器 @Bean public CaffeineCacheManager caffeineCacheManager() { CaffeineCacheManager cacheManager = new CaffeineCacheManager(); cacheManager.setCaffeine(Caffeine.newBuilder() .expireAfterWrite(10, TimeUnit.MINUTES) .maximumSize(1000)); return cacheManager; } // 配置多级缓存管理器（组合Caffeine和Redis） @Primary @Bean public CacheManager multiLevelCacheManager(CaffeineCacheManager caffeineCacheManager, RedisCacheManager redisCacheManager) { // 这里需要自定义一个组合缓存管理器，可以使用已有的开源实现或者自己实现 // 通常，读取时先读本地缓存，再读Redis；写入时同时写入两级缓存 // 注意：需要处理缓存同步和一致性问题 return new MultiLevelCacheManager(caffeineCacheManager, redisCacheManager); } } ``` 注意：上述代码中的MultiLevelCacheManager需要自定义实现，它负责协调两级缓存。同时，为了保持缓存一致性，当数据更新时，需要使所有节点的一级缓存失效，这可以通过Redis的发布/订阅机制实现（如引用[2]所述）。 另外，引用[3]中提到了使用条件注解来控制本地缓存的开关，我们可以这样实现： ```java @Configuration @ConditionalOnProperty(name = "cache.local.enabled", havingValue = "true") public class LocalCacheConfig { // 配置本地缓存相关的Bean } ``` 这样，通过配置文件中的`cache.local.enabled`属性，可以动态开启或关闭本地缓存。 综上所述，Spring Boot可以同时集成Caffeine和Redis，构建多级缓存系统，并通过配置灵活控制。 生成相关问题： 1. 如何自定义多级缓存管理器（MultiLevelCacheManager）？ 2. 如何利用Redis的发布/订阅实现缓存同步？ 3. 在Spring Boot中配置多级缓存时，需要注意哪些问题？</think>在 Spring Boot 项目中，**可以同时集成 Caffeine 和 Redis 缓存**，形成多级缓存架构（本地缓存 + 分布式缓存）。这种组合能显著提升系统性能，同时解决分布式环境下的缓存一致性问题。以下是关键实现方案： --- ### **一、实现原理** 1. **两级缓存架构** - **一级缓存（本地）**：使用 Caffeine 提供超高速访问（纳秒级响应），适合高频访问的热点数据。 - **二级缓存（分布式）**：使用 Redis 保证多节点间数据一致性，作为后备存储。 ```mermaid graph LR A[应用] --> B[Caffeine 本地缓存] B -->|缓存未命中| C[Redis 分布式缓存] C -->|缓存未命中| D[数据库] ``` 2. **缓存同步机制** - 通过 Redis 的 **发布/订阅（Pub/Sub）** 功能同步各节点的本地缓存（如引用[2]所述）。 - 当某节点修改数据时，发布消息使其他节点失效本地缓存。 --- ### **二、集成步骤** #### 1. **添加 Maven 依赖** ```xml <!-- Caffeine --> <dependency> <groupId>com.github.ben-manes.caffeine</groupId> <artifactId>caffeine</artifactId> </dependency> <!-- Redis --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> ``` #### 2. **启用缓存（启动类）** ```java @SpringBootApplication @EnableCaching // 开启缓存抽象 public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } } ``` #### 3. **配置多级缓存管理器** ```java @Configuration public class CacheConfig { @Bean public CacheManager cacheManager(RedisConnectionFactory factory) { // Caffeine 作为一级缓存（本地） CaffeineCacheManager caffeineCacheManager = new CaffeineCacheManager(); caffeineCacheManager.setCaffeine(Caffeine.newBuilder() .expireAfterWrite(10, TimeUnit.MINUTES) // 本地缓存过期时间 .maximumSize(1000) ); // Redis 作为二级缓存（分布式） RedisCacheManager redisCacheManager = RedisCacheManager.create(factory); // 组合多级缓存（优先本地，其次Redis） return new MultiLevelCacheManager(caffeineCacheManager, redisCacheManager); } } ``` #### 4. **实现缓存同步（关键）** 通过 Redis 发布/订阅同步本地缓存失效（如引用[2]）： ```java @Bean public RedisMessageListenerContainer container(RedisConnectionFactory factory) { RedisMessageListenerContainer container = new RedisMessageListenerContainer(); container.setConnectionFactory(factory); container.addMessageListener(new MessageListenerAdapter(this), new ChannelTopic("cache-invalidate")); return container; } // 收到消息时失效本地缓存 public void handleMessage(String cacheKey) { caffeineCacheManager.getCache(cacheKey).clear(); } ``` #### 5. **动态开关本地缓存（如引用[3]）** ```java @Configuration @ConditionalOnProperty( // 通过配置控制开关 name = "cache.local.enabled", havingValue = "true", matchIfMissing = false ) public class LocalCacheConfig { @Bean public CaffeineCacheManager caffeineCacheManager() { // 本地缓存配置 } } ``` 配置文件 `application.yml`： ```yaml cache: local: enabled: true # 动态启用/禁用 Caffeine ``` --- ### **三、使用缓存示例** ```java @Service public class UserService { @Cacheable(value = "users", key = "#id") // 自动使用多级缓存 public User getUserById(Long id) { return userRepository.findById(id); // 数据库查询 } @CacheEvict(value = "users", key = "#id") public void updateUser(User user) { // 更新数据后发布缓存失效消息 redisTemplate.convertAndSend("cache-invalidate", "users:" + user.getId()); } } ``` --- ### **四、优势与适用场景** | **优势** | **适用场景** | |-------------------------|----------------------------------| | **高性能**：Caffeine 本地缓存响应极快 | 高频读取的热点数据（如商品详情） | | **一致性**：Redis 保证多节点同步 | 分布式集群环境 | | **灵活性**：动态开关本地缓存 | 测试环境降级、流量高峰控制 | > **注意**：需权衡本地缓存带来的内存消耗，建议通过 `maximumSize` 限制缓存条目（如引用[3]）。 --- ### **相关问题** 1. 如何解决 Caffeine 和 Redis 之间的数据一致性问题？ 2. 在多级缓存架构中，如何设计缓存穿透和雪崩的保护机制？ 3. 如何监控 Spring Boot 中 Caffeine 和 Redis 的缓存命中率？ [^1]: Spring Boot 使用多级缓存 {Caffeine+Redis}，快速入门示例 [^2]: 基于 Redis 发布/订阅实现分布式缓存同步 [^3]: 通过 `@ConditionalOnProperty` 动态控制本地缓存开关
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值