SpringBoot项目实战：Caffeine本地缓存如何提升微服务性能？附完整配置代码

关注

原创最新推荐文章于 2026-09-18 14:18:42 发布 420 阅读 AI 写同款· GEO 优化 ›

告别Guava Cache：SpringBoot项目迁移到Caffeine 3.x的完整指南与性能对比本文详细介绍了如何将SpringBoot项目中的Guava Cache迁移到Caffeine 3.x，包括性能对比、迁移步骤和高级调优技巧。Caffeine 3.x凭借无锁并发和Window-TinyLFU算法，显著提升缓存命中率和性能，适用于高并发场景。通过实战案例和配置示例，帮助开发者顺利完成迁移并优化缓存架构。阅读详情

SpringBoot项目实战：Caffeine本地缓存如何提升微服务性能？附完整配置代码

在微服务架构的浪潮下，服务间的调用变得日益频繁，数据访问的延迟和数据库的压力也随之成为性能瓶颈的“重灾区”。你是否遇到过这样的场景：一个用户信息查询接口，在业务高峰期每秒被调用上千次，每次都要穿透到数据库，不仅响应时间拉长，数据库连接池也频频告急。这时候，一个设计精良的本地缓存，就像是给服务内部装上了一台高速的“内存数据库”，能瞬间将热点数据的访问速度提升几个数量级。

Caffeine正是为此而生的高性能本地缓存库。它并非简单的键值对存储，而是融合了现代算法智慧，针对高并发场景深度优化的产物。对于Java中高级开发者而言，掌握Caffeine不仅仅是学会一个API，更是理解如何在内存、CPU与I/O之间寻找最佳平衡点，构建出既快又稳的服务内部数据层。本文将抛开理论堆砌，直接从实战出发，手把手带你将Caffeine深度整合进SpringBoot，并探讨如何用它来化解微服务中的典型性能困局。

1. 为什么是Caffeine？超越Guava Cache的性能哲学

在本地缓存的世界里，Guava Cache曾是许多开发者的首选。它简单易用，功能齐全。但当面对现代微服务中动辄数千QPS、数据访问模式复杂多变的场景时，其底层采用的LRU（最近最少使用）淘汰策略开始显得力不从心。Caffeine的诞生，正是为了解决传统算法在应对“突发稀疏流量”和“频率统计开销”时的固有缺陷。

Caffeine的核心竞争力在于其采用的 W-TinyLFU（Window Tiny Least Frequently Used） 淘汰算法。为了理解它的精妙，我们不妨先看看传统算法的短板：

LRU（最近最少使用）：只关心数据最近一次被访问的时间。假设一个热门商品数据被频繁访问了59秒，但在第60秒有一批冷门数据涌入，LRU很可能因为“最近”未访问而将热门商品淘汰，导致缓存污染。
LFU（最不经常使用）：统计每个数据的访问频率，淘汰频率最低的。这听起来合理，但它有两个致命伤：一是需要为每个条目维护一个计数器，每次访问都要更新，内存和CPU开销大；二是对历史数据有“记忆”，新来的热点数据可能因为初始频率低而永远无法进入缓存。

W-TinyLFU巧妙地融合了LRU和LFU的思想，并通过Count-Min Sketch这个概率数据结构来低成本、高效率地估算访问频率。你可以把它想象成一个“频率素描本”，用极小的空间（几个long型数组）和哈希函数，近似地记录海量key的访问次数，且能容忍一定的误差。这种用精度换空间和速度的设计，在高并发缓存场景下非常划算。

更关键的是，W-TinyLFU引入了**窗口队列（Window Deque）**的设计。所有新到的数据首先进入这个窗口区域。这给了突发性热点数据一个“亮相”的机会。只有那些在窗口期内被再次访问（证明其可能是真热点）的数据，才会被晋升到受保护的主缓存区。这种机制完美应对了“一炮而红”的新数据场景。

为了直观感受算法带来的差异，我们可以看一个简单的性能对照。在同样的硬件环境下，对读写混合场景进行压测：

操作类型	缓存库	平均耗时 (纳秒)	99.9%分位耗时 (纳秒)	备注
并发读	Guava Cache	~120	~450	随着并发上升，耗时增长明显
并发读	Caffeine	~45	~180	表现稳定，尾部延迟低
并发写	Guava Cache	~200	~850	写锁竞争导致性能下降
并发写	Caffeine	~80	~320	更优的并发写策略
读写混合(8:2)	Guava Cache	~150	~600	综合场景下瓶颈显现
读写混合(8:2)	Caffeine	~60	~250	整体性能提升约2.5倍

提示：上述数据来源于简化版的JMeter基准测试，实际提升幅度取决于数据大小、访问模式、硬件配置等因素。但趋势是明确的：在高并发下，Caffeine的优势会被放大。

所以，选择Caffeine，不仅是选择一个更快的缓存，更是选择了一种更适应现代高并发、动态数据访问模式的设计哲学。

2. SpringBoot与Caffeine的深度集成实战

理解了“为什么用”，接下来就是“怎么用”。Spring Boot提供了优雅的缓存抽象（spring-boot-starter-cache），让我们能以声明式的方式使用缓存，而Caffeine可以无缝作为其提供者。我们从一个电商平台的用户服务实战开始。

2.1 基础依赖与配置

首先，在pom.xml中引入必要的依赖。注意，我们直接使用Spring Boot管理的Caffeine依赖，可以避免版本冲突。

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-cache</artifactId>
    </dependency>
    <dependency>
        <groupId>com.github.ben-manes.caffeine</groupId>
        <artifactId>caffeine</artifactId>
        <!-- 版本通常由Spring Boot管理 -->
    </dependency>
    <!-- 可选，用于监控和统计 -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
</dependencies>

接下来，在application.yml中配置Caffeine作为默认缓存管理器，并定义几个针对不同场景的缓存配置。

spring:
  cache:
    type: caffeine
    caffeine:
      spec: maximumSize=500,expireAfterWrite=60s,recordStats
    cache-names: userCache, productCache, configCache
  # 启用Actuator的缓存端点，方便观察
management:
  endpoints:
    web:
      exposure:
        include: health,info,caches

这里我们通过caffeine.spec配置了全局默认参数：最大容量500条，写入后60秒过期，并开启统计。cache-names预定义了三个缓存名称。

2.2 高级缓存配置类

对于更精细的控制，我们需要一个配置类。例如，我们希望userCache（用户信息）容量大、过期时间长，而configCache（动态配置）则需要支持软引用，在内存紧张时能被GC回收。

import com.github.benmanes.caffeine.cache.Caffeine;
import org.springframework.cache.CacheManager;
import org.springframework.cache.caffeine.CaffeineCacheManager;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Primary;

import java.util.concurrent.TimeUnit;

@Configuration
public class CaffeineCacheConfig {

    @Bean
    @Primary
    public CacheManager cacheManager() {
        CaffeineCacheManager cacheManager = new CaffeineCacheManager();
        // 默认配置（适用于未特殊指定的缓存）
        cacheManager.setCaffeine(Caffeine.newBuilder()
                .maximumSize(500)
                .expireAfterWrite(60, TimeUnit.SECONDS)
                .recordStats() // 记录统计信息，便于监控
        );
        // 为特定缓存名称设置自定义配置
        cacheManager.setCacheSpecification("userCache", Caffeine.newBuilder()
                .maximumSize(10000) // 用户缓存容量更大
                .expireAfterAccess(30, TimeUnit.MINUTES) // 30分钟无访问则过期
                .recordStats()
                .build());
        cacheManager.setCacheSpecification("productCache", Caffeine.newBuilder()
                .maximumSize(2000)
                .expireAfterWrite(10, TimeUnit.MINUTES)
                .refreshAfterWrite(5, TimeUnit.MINUTES) // 写入5分钟后异步刷新
                .recordStats()
                .build());
        cacheManager.setCacheSpecification("configCache", Caffeine.newBuilder()
                .maximumSize(100)
                .softValues() // 使用软引用，内存不足时可被回收
                .expireAfterWrite(24, TimeUnit.HOURS)
                .recordStats()
                .build());
        return cacheManager;
    }
}

关键点解析：

expireAfterAccess vs expireAfterWrite：对于用户信息这类“读多写少”的数据，使用expireAfterAccess更合理，只要用户活跃，数据就一直有效。对于商品信息，使用expireAfterWrite能保证数据的相对新鲜度。
refreshAfterWrite：这是一个非常实用的特性。配置了refreshAfterWrite(5m)后，数据在写入5分钟后，下一次访问时会触发异步刷新（调用原方法加载新数据），但立即返回旧值。这避免了缓存失效瞬间大量请求穿透数据库导致的“缓存雪崩”和“击穿”。
softValues()：用于configCache，表示缓存值被软引用持有。当JVM内存不足时，这些缓存条目会被垃圾回收器优先回收，从而为应用程序腾出内存，是一种“优雅降级”策略。

2.3 声明式缓存注解实战

Spring的缓存注解让缓存的使用变得极其简洁。我们以一个UserService为例。

import org.springframework.cache.annotation.CacheEvict;
import org.springframework.cache.annotation.CachePut;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.cache.annotation.Caching;
import org.springframework.stereotype.Service;
import lombok.extern.slf4j.Slf4j;

@Service
@Slf4j
public class UserService {

    // 1. 查询：缓存命中则直接返回，未命中则执行方法并缓存结果
    @Cacheable(value = "userCache", key = "#userId", unless = "#result == null")
    public UserDTO getUserById(Long userId) {
        log.info("缓存未命中，查询数据库获取用户: {}", userId);
        // 模拟数据库查询
        return userRepository.findById(userId)
                .map(this::convertToDTO)
                .orElse(null);
    }

    // 2. 更新/保存：总是执行方法，并用结果更新缓存
    @CachePut(value = "userCache", key = "#user.id")
    public UserDTO updateUser(User user) {
        log.info("更新用户信息并刷新缓存: {}", user.getId());
        User savedUser = userRepository.save(user);
        return convertToDTO(savedUser);
    }

    // 3. 删除：清除指定key的缓存
    @CacheEvict(value = "userCache", key = "#userId")
    public void deleteUser(Long userId) {
        log.info("删除用户并清除缓存: {}", userId);
        userRepository.deleteById(userId);
    }

    // 4. 复杂场景：同时操作多个缓存
    @Caching(evict = {
        @CacheEvict(value = "userCache", key = "#userId"),
        @CacheEvict(value = "userProductCache", allEntries = true) // 清除该缓存所有条目
    })
    public void deactivateUser(Long userId) {
        log.info("禁用用户，并清理相关缓存");
        // ... 业务逻辑
    }

    // 5. 条件缓存：仅当满足条件时才缓存
    @Cacheable(value = "userCache",
               key = "#userId",
               condition = "#userId > 1000", // 只缓存ID大于1000的用户
               unless = "#result.age < 18") // 结果中年龄小于18的不缓存
    public UserDTO getUserWithCondition(Long userId) {
        // ...
    }

    private UserDTO convertToDTO(User user) {
        // 实体转DTO逻辑
        return new UserDTO(user.getId(), user.getName(), user.getEmail());
    }
}

注意：@Cacheable注解中的sync属性（默认为false）。在高并发场景下，如果缓存失效，多个线程可能同时执行方法体。设置sync = true会对该key的加载过程加锁，确保只有一个线程执行加载，其他线程等待结果。这能有效防止缓存击穿，但会轻微增加响应时间。需要根据业务容忍度权衡。

3. 应对微服务缓存典型问题：雪崩、击穿与穿透

集成只是第一步，在分布式环境下，本地缓存使用不当会引入新的问题。我们必须主动设计防御策略。

3.1 缓存雪崩预防策略

问题：大量缓存数据在同一时刻过期失效，导致所有请求瞬间穿透到数据库，造成数据库压力激增甚至宕机。

Caffeine解决方案：

差异化过期时间：这是最基本也最有效的方法。不要在配置中为所有数据设置相同的expireAfterWrite时间。可以添加一个随机因子。

@Bean
public CacheManager cacheManager() {
    CaffeineCacheManager manager = new CaffeineCacheManager();
    manager.setCaffeine(Caffeine.newBuilder()
        .maximumSize(1000)
        // 基础时间 + 随机偏移量，打散过期时间点
        .expireAfterWrite(60 + ThreadLocalRandom.current().nextInt(0, 30), TimeUnit.SECONDS)
        .recordStats());
    return manager;
}

使用refreshAfterWrite：如前所述，此策略在数据过期后，不会立即清除，而是标记为待刷新。下次访问时异步加载新数据并返回旧值，平滑了数据库压力。
二级缓存兜底：对于极其关键的数据，可以考虑引入一个容量更小、过期时间更长的二级本地缓存（或使用Redis作为分布式缓存备份），在Caffeine缓存失效时，先查二级缓存。

3.2 缓存击穿应对方案

问题：某个热点key失效的瞬间，大量并发请求同时涌向数据库，仿佛击穿了一个点。

Caffeine解决方案：

互斥锁（Mutex Lock）：利用@Cacheable(sync = true)。这是最直接的方案，确保只有一个线程执行加载。
逻辑过期：不在缓存中存储数据的过期时间，而是存储一个包含数据本身和逻辑过期时间的封装对象。当发现数据逻辑上已过期，不是立即去加载，而是发起一个异步更新任务，当前请求仍返回旧数据。这需要业务层做一些额外封装。
永不过期策略：对于极热且变化不频繁的数据（如城市列表、基础配置），可以设置为永不过期，通过后台任务或消息队列来主动更新缓存。Caffeine本身不提供“永不过期”，但可以将expireAfterWrite设置为一个极长的时间（如7天），并配合refreshAfterWrite进行后台更新。

3.3 缓存穿透的防御

问题：查询一个数据库中根本不存在的数据（如不存在的用户ID），每次请求都会穿透缓存到达数据库。

Caffeine解决方案：

缓存空对象：在@Cacheable中，即使查询结果为null，也将其缓存起来，并设置一个较短的过期时间（如30秒）。这能防止短时间内对同一个不存在key的反复攻击。

@Cacheable(value = "userCache", key = "#userId")
public UserDTO getUserById(Long userId) {
    User user = userRepository.findById(userId).orElse(null);
    if (user == null) {
        // 可以缓存一个特殊的空对象标记
        return NullUserDTO.INSTANCE;
    }
    return convertToDTO(user);
}

同时，在@CachePut和业务逻辑中，需要处理这种特殊空对象的更新。

布隆过滤器前置：在查询Caffeine缓存之前，先经过一个布隆过滤器（Bloom Filter）判断key是否可能存在。如果布隆过滤器说“不存在”，则直接返回空，避免了对Caffeine和数据库的访问。Caffeine本身不内置布隆过滤器，需要结合Guava或Redis实现。

4. 监控、调优与高级特性

部署上线后，我们需要知道缓存效果如何，并据此进行调优。Caffeine提供了丰富的监控指标。

4.1 利用Actuator与CacheStats监控

当我们配置了recordStats()后，可以通过Spring Boot Actuator的/actuator/caches和/actuator/caches/{cacheName}端点查看缓存的基本信息。但要获取更详细的命中率、加载时间等，需要直接访问CacheStats。

我们可以创建一个简单的监控服务：

import com.github.benmanes.caffeine.cache.stats.CacheStats;
import org.springframework.cache.CacheManager;
import org.springframework.cache.caffeine.CaffeineCache;
import org.springframework.stereotype.Service;
import javax.annotation.Resource;
import java.util.HashMap;
import java.util.Map;

@Service
public class CacheMonitorService {

    @Resource
    private CacheManager cacheManager;

    public Map<String, Map<String, Object>> getCacheStats() {
        Map<String, Map<String, Object>> statsMap = new HashMap<>();
        cacheManager.getCacheNames().forEach(cacheName -> {
            org.springframework.cache.Cache springCache = cacheManager.getCache(cacheName);
            if (springCache != null && springCache.getNativeCache() instanceof com.github.benmanes.caffeine.cache.Cache) {
                com.github.benmanes.caffeine.cache.Cache<Object, Object> caffeineCache =
                        (com.github.benmanes.caffeine.cache.Cache<Object, Object>) springCache.getNativeCache();
                CacheStats stats = caffeineCache.stats();

                Map<String, Object> stat = new HashMap<>();
                stat.put("hitCount", stats.hitCount());
                stat.put("missCount", stats.missCount());
                stat.put("loadSuccessCount", stats.loadSuccessCount());
                stat.put("loadFailureCount", stats.loadFailureCount());
                stat.put("totalLoadTime", stats.totalLoadTime());
                stat.put("evictionCount", stats.evictionCount());
                stat.put("evictionWeight", stats.evictionWeight());
                // 计算命中率
                double hitRate = stats.hitRate(); // 0.0 ~ 1.0
                double missRate = stats.missRate();
                stat.put("hitRate", String.format("%.2f%%", hitRate * 100));
                stat.put("missRate", String.format("%.2f%%", missRate * 100));
                stat.put("averageLoadPenalty", stats.averageLoadPenalty() + " ns");

                statsMap.put(cacheName, stat);
            }
        });
        return statsMap;
    }
}

然后通过一个控制器暴露接口，或集成到公司的监控平台。重点关注命中率（hitRate）和平均加载耗时（averageLoadPenalty）。如果命中率过低（如低于80%），可能需要调整缓存容量或淘汰策略；如果平均加载耗时过长，则需要优化数据加载逻辑本身。

4.2 基于权重的淘汰策略

除了基于大小的淘汰，Caffeine支持基于权重的淘汰。这对于缓存对象大小差异巨大的场景非常有用。例如，缓存内容可能是几KB的配置，也可能是几MB的报表HTML。

@Bean
public CacheManager reportCacheManager() {
    CaffeineCacheManager manager = new CaffeineCacheManager("largeReportCache");
    manager.setCaffeine(Caffeine.newBuilder()
        .maximumWeight(100 * 1024 * 1024) // 最大权重设为100MB
        .weigher((String key, String reportContent) -> reportContent.getBytes().length) // 权重=内容字节数
        .expireAfterWrite(2, TimeUnit.HOURS)
        .recordStats());
    return manager;
}

这样，缓存会确保所有条目总大小不超过100MB，而不是简单的条目数量限制。

4.3 异步加载与刷新

对于加载成本高昂的操作（如调用外部API、复杂计算），应使用异步加载，避免阻塞请求线程。

import com.github.benmanes.caffeine.cache.AsyncLoadingCache;
import com.github.benmanes.caffeine.cache.Caffeine;
import org.springframework.stereotype.Component;
import javax.annotation.PostConstruct;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.TimeUnit;

@Component
public class ExpensiveDataLoader {

    private AsyncLoadingCache<String, String> asyncCache;

    @PostConstruct
    public void init() {
        asyncCache = Caffeine.newBuilder()
                .maximumSize(1000)
                .expireAfterWrite(10, TimeUnit.MINUTES)
                .refreshAfterWrite(1, TimeUnit.MINUTES) // 异步刷新
                .buildAsync(key -> loadDataFromExpensiveSource(key)); // 异步加载函数
    }

    public CompletableFuture<String> getData(String key) {
        return asyncCache.get(key);
    }

    private String loadDataFromExpensiveSource(String key) {
        // 模拟耗时操作
        try {
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        return "Expensive data for " + key + " at " + System.currentTimeMillis();
    }
}

在Service中，你可以这样使用：

public CompletableFuture<Report> getReportAsync(String reportId) {
    return expensiveDataLoader.getData(reportId)
            .thenApply(data -> convertToReport(data));
}

4.4 监听器与事件驱动

Caffeine提供了移除监听器（removalListener），允许你在条目被移除（过期、被淘汰、显式删除）时执行一些操作，比如记录日志、发送通知或更新二级缓存。

Caffeine.newBuilder()
    .maximumSize(1000)
    .expireAfterWrite(10, TimeUnit.MINUTES)
    .removalListener((String key, Object value, RemovalCause cause) -> {
        log.warn("缓存条目被移除. Key: {}, Cause: {}", key, cause);
        // 根据cause做不同处理
        if (cause == RemovalCause.EXPIRED) {
            metricsCounter.increment("cache.expired");
        } else if (cause == RemovalCause.SIZE) {
            metricsCounter.increment("cache.evicted");
        }
    })
    .build();

在实际项目中，我将Caffeine的这些特性组合使用，为核心的订单查询服务构建了缓存层。最初使用简单的@Cacheable，命中率只有70%左右，尾部延迟较高。后来通过分析CacheStats，发现是缓存容量不足导致频繁淘汰。调整maximumSize并引入基于权重的策略后，命中率稳定在95%以上。同时，为几个超热点商品数据设置了refreshAfterWrite，彻底消除了缓存失效瞬间的毛刺。监控上的曲线变得平滑，数据库的QPS下降了近80%。这个过程让我深刻体会到，好的工具需要配合细致的调优和监控，才能发挥最大威力。