JCache缓存预热实战：JSR-107规范与生产实践

做个Java后端这些年，缓存是我天天打交道的工具，但我慢慢发现，“会用Redis”和“懂缓存抽象”完全是两条赛道。最近做面试复盘，十个候选人里有八个听到JCache（JSR-107）都会愣一下。今天我就借着“如何通过JCache API实现一个简单的缓存预热（Cache Warm-up）逻辑”这道题，把JCache最核心的用法和预热场景一起讲透。这道题表面是考API，实际是在考你有没有认真读过缓存规范的抽象层次，有没有处理过冷启动、并发预热这类生产问题。无论你是准备高级Java面试，还是想把项目中写死的Redis/Caffeine调用换成可插拔的缓存方案，这篇都值得花十分钟看完。

1. 先把JCache的底裤翻出来：它不是缓存，是缓存规范

1.1 JSR-107的来龙去脉

很多同学一听“JSR-107”就以为是某个具体缓存组件，其实完全不是。JSR-107，也就是JCache，是Java社区在JCP下制定的临时缓存API标准，2014年正式发布1.0版本，到现在javax.cache这个坐标还在持续演进，常见的是1.1.x。

你可以把它理解成JDBC之于数据库的关系：JDBC不关心你到底连的是MySQL还是PostgreSQL，它只定义“连数据库、发SQL、取结果”这些标准动作；JCache也不关心底层是Ehcache、Hazelcast还是Infinispan，它只定义“拿缓存管理器、建缓存、读写数据、配过期策略”这些标准动作。

这个抽象很值钱。一旦你的业务代码全部依赖javax.cache接口，底层实现就可以随时替换。今天用Ehcache，明天想换Hazelcast做分布式缓存，业务代码基本不用动，只需要调整依赖和启动配置。

1.2 JCache四大核心接口

JCache的API并不复杂，核心就四样东西：

• CachingProvider：缓存提供方入口，通过Caching.getCachingProvider()拿到。它负责创建CacheManager。一个Provider可以管理多个CacheManager。
• CacheManager：缓存管理器，负责创建、查找和销毁Cache。你可以把它类比成连接池里的DataSource，是操作缓存的总入口。
• Cache<K, V>：真正读写数据的对象，行为像一个增强版的Map，但多了过期策略、驱逐策略、监听器、统计信息、原子操作这些能力。
• CacheEntry<K, V>：缓存里的一条数据，一般你不太会直接使用它，更多是在遍历和监听器回调里出现。

其中Cache接口的方法值得多看一眼：get、put、putIfAbsent、remove、replace、getAll、putAll、iterator、invoke。尤其putIfAbsent和invoke，在实现分布式锁、原子更新时有奇效，后面讲并发预热时会用到。

1.3 面试官为什么爱考这个冷门规范

说实话，JCache在国内实际项目里用得并不多，很多人知道Redis、Caffeine，但从来没听过JSR-107。面试官问这个，不是真指望你把API背得多熟，而是想看三件事：

第一，你有没有了解过缓存之上的抽象层。如果只知道StringRedisTemplate.opsForValue().set()，说明你停留在工具使用层面，缺少框架思维。

第二，你能否解释清楚规范和实现的关系。这是典型的“面向接口编程”考题。

第三，你能不能把一个看似简单的“预热”需求，落实到API和代码层面，并且把并发、异常、过期这些生产问题考虑进去。

所以，这道题真正想筛选的，是那种既懂理论又能落地的候选人。

2. 缓存预热到底在解决什么问题

2.1 冷启动瞬间打爆数据库的真实场景

想象一个典型的电商首页，用户点开App第一屏就要展示热门商品、分类导航、促销活动。这些数据通常都是查数据库后计算出来的，读取频繁，而且实时性要求没那么高。

应用刚启动时，缓存是空的。如果这时候流量直接涌进来，每个请求都查一次数据库，数据库瞬间就可能被压垮。尤其是秒杀、大促这类场景，流量是平时的几十倍，冷启动的杀伤力会被无限放大。

缓存预热要解决的就是这个问题：在业务请求到达之前，先把热点数据主动塞进缓存，让系统从第一秒开始就能用缓存抗住流量。说白了，就是“上场之前先把子弹上膛”。

2.2 哪些数据值得预热：三看原则

不是所有数据都要预热，盲目预热反而浪费启动时间、占用内存。我一般按三个原则来判断：

一看数据量。数据量可控最好，比如几万、几十万级别的热点数据。如果是几亿条全量数据，预热本身就会把DB拖垮，就得分层处理了。

二看访问频率。高频访问但低频变化的数据最适合预热，比如配置信息、商品基础信息、用户会话摘要。

三看失效成本。如果缓存一旦失效，数据库直接承受巨大压力，那这种数据无论如何都要预热。

典型的场景包括：秒杀商品库存、首页Feed流、排行榜、权限配置、多租户的租户配置等。

2.3 “简单”二字背后的三个深坑

题目里强调“简单的缓存预热逻辑”，面试官其实是在挖坑。因为真正做过的人都知道，预热看起来就是“查出数据，塞进缓存”，但落地时至少有三个坑：

第一，重复预热。多台应用实例同时启动，每台机器都去数据库拉一遍热点数据，数据库会被重复打穿。

第二，失败处理。预热时如果数据库刚好抖动，你到底让应用启动失败，还是降级成“先空缓存启动再慢慢补”？

第三，节奏匹配。缓存过期时间和定时预热周期如果没对齐，会出现“刚预热完就过期”或者“缓存快空了才想起来预热”的尴尬局面。

后面我会对应给出解决方案，这些才是面试中的加分点。

3. 手把手实现一个JCache预热组件

3.1 依赖选型：为什么用Ehcache做演示

JCache只是接口，必须搭配一个实现。我习惯用Ehcache来演示，原因很简单：Ehcache 3从底层原生支持JSR-107，依赖引入最少，配置也直观，本地跑起来最省事。

Maven坐标：

xml复制<dependency>
    <groupId>javax.cache</groupId>
    <artifactId>cache-api</artifactId>
    <version>1.1.1</version>
</dependency>
<dependency>
    <groupId>org.ehcache</groupId>
    <artifactId>ehcache</artifactId>
    <version>3.10.8</version>
</dependency>

如果是Gradle项目，对应改成implementation 'javax.cache:cache-api:1.1.1'和implementation 'org.ehcache:ehcache:3.10.8'即可。

注意一点：只要classpath里有JCache实现，Caching.getCachingProvider()就能通过SPI机制自动发现它。如果同时存在多个实现，规范默认返回第一个被发现的Provider，你也可以通过Caching.getCachingProvider("org.ehcache.jsr107.EhcacheCachingProvider")强制指定。

3.2 创建缓存：别把配置写死

先看一段完整的缓存创建代码：

java复制import javax.cache.Cache;
import javax.cache.CacheManager;
import javax.cache.Caching;
import javax.cache.configuration.MutableConfiguration;
import javax.cache.expiry.CreatedExpiryPolicy;
import javax.cache.expiry.Duration;
import javax.cache.spi.CachingProvider;

CachingProvider provider = Caching.getCachingProvider();
CacheManager cacheManager = provider.getCacheManager();

MutableConfiguration<String, String> config = new MutableConfiguration<String, String>()
        .setTypes(String.class, String.class)
        .setStoreByValue(true)
        .setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(Duration.ONE_HOUR));

Cache<String, String> userCache = cacheManager.createCache("userCache", config);

这里有几个配置我建议你显式写清楚，不要依赖默认值：

• setTypes：指定key和value的类型，避免运行时类型混乱。
• setStoreByValue(true)：JCache规范默认就是true，表示缓存里存对象的副本而不是引用，需要value实现序列化。如果存普通POJO且没做序列化处理，运行时会直接报NotSerializableException。
• setExpiryPolicyFactory：这里用的是CreatedExpiryPolicy，表示从条目创建开始算过期时间。还有ModifiedExpiryPolicy（更新后重新计时）、AccessedExpiryPolicy（访问后重新计时）。

如果缓存已经存在，createCache会抛异常。更稳妥的写法是先查再建：

java复制Cache<String, String> userCache = cacheManager.getCache("userCache", String.class, String.class);
if (userCache == null) {
    userCache = cacheManager.createCache("userCache", config);
}

3.3 核心预热方法：用putAll批量写入

预热最核心的逻辑就是“从数据源加载一堆数据，再写进缓存”。我习惯把它封装成一个与具体业务无关的方法：

java复制import java.util.Map;
import java.util.function.Supplier;

public <K, V> void warmUp(Cache<K, V> cache, Supplier<Map<K, V>> dataLoader) {
    Map<K, V> data = dataLoader.get();
    if (data == null || data.isEmpty()) {
        return;
    }
    cache.putAll(data);
}

这个方法的通用性很强：数据源可能是数据库查询结果，可能是RPC接口返回，也可能是本地配置文件解析结果，只需要包装成Supplier<Map<K, V>>传进来就行。

再举一个具体的业务例子。假设要给用户信息做预热，缓存里存用户ID到用户摘要JSON字符串的映射：

java复制public class UserCacheWarmup {
    private final Cache<String, String> userCache;
    private final UserRepository userRepository;

    public UserCacheWarmup(Cache<String, String> userCache, UserRepository userRepository) {
        this.userCache = userCache;
        this.userRepository = userRepository;
    }

    public void warmUp() {
        List<User> users = userRepository.findActiveUsers();
        if (users.isEmpty()) {
            return;
        }
        Map<String, String> data = new HashMap<>(users.size());
        for (User user : users) {
            data.put(user.getId(), user.toCacheJson());
        }
        userCache.putAll(data);
        System.out.println("userCache warmup finished, size=" + data.size());
    }
}

为什么用putAll而不是循环put？一方面代码更简洁，语义更清晰；另一方面，像Ehcache这类实现在处理批量操作时可以在引擎层做一些优化，减少锁竞争和日志开销。但你要注意，putAll并不是一个原子操作，如果中途发生异常，可能只写入了一部分数据，所以大批量预热时要分批处理，比如每500个一批。

3.4 启动时触发与定时刷新：两种落地姿势

写好了预热方法，还需要决定什么时候触发。最常见的两种：应用启动时跑一次、定时周期性刷新。

如果项目用的是Spring Boot，启动时预热可以直接实现ApplicationRunner：

java复制@Component
public class CacheWarmupRunner implements ApplicationRunner {
    private final UserCacheWarmup userCacheWarmup;

    public CacheWarmupRunner(UserCacheWarmup userCacheWarmup) {
        this.userCacheWarmup = userCacheWarmup;
    }

    @Override
    public void run(ApplicationArguments args) {
        userCacheWarmup.warmUp();
    }
}

这里要注意，ApplicationRunner会在Spring容器启动完成后执行，这时候依赖注入已经完成，可以安全使用Bean。如果多个Runner之间存在先后依赖，可以用@Order控制顺序。

定时刷新可以用Spring的@Scheduled：

java复制@Component
public class CacheRefreshTask {
    private final UserCacheWarmup userCacheWarmup;

    public CacheRefreshTask(UserCacheWarmup userCacheWarmup) {
        this.userCacheWarmup = userCacheWarmup;
    }

    @Scheduled(fixedDelay = 30 * 60 * 1000L, initialDelay = 60 * 1000L)
    public void refresh() {
        userCacheWarmup.warmUp();
    }
}

fixedDelay表示上一次任务执行完，再延迟30分钟开始下一次，这种方式天然避免了任务重叠。initialDelay = 60 * 1000L表示应用启动1分钟后再跑第一次定时预热，既避开了启动高峰期，又能补充启动时漏掉的数据。

3.5 加分项：结合Read-Through做缺省加载

面试时如果只讲到手动预热，已经能拿基础分了。想再往上走，可以提一下CacheLoader。JCache支持Read-Through模式，也就是配置一个CacheLoader，当缓存miss时会自动回调加载逻辑：

java复制MutableConfiguration<String, User> config = new MutableConfiguration<String, User>()
        .setTypes(String.class, User.class)
        .setReadThrough(true)
        .setCacheLoaderFactory(() -> new CacheLoader<String, User>() {
            @Override
            public User load(String key) {
                return userRepository.findById(key);
            }

            @Override
            public Map<String, User> loadAll(Iterable<? extends String> keys) {
                return userRepository.findByIds(keys);
            }
        });

手动预热负责“事前把热点数据备好”，Read-Through负责“事后兜底冷数据”。两者结合，既解决了冷启动问题，又避免了漏掉的数据在第一次被访问时穿透到数据库。这个组合在面试里说出来，会让面试官觉得你对JCache有整体认识。

4. 我踩过的坑，你千万别再踩

4.1 storeByValue导致NotSerializableException

第一次用JCache存对象时，我在本地跑得挺好，一上线就报错，日志里写着java.io.NotSerializableException。原因就是MutableConfiguration默认storeByValue=true，缓存会把value序列化一份副本存起来，而我的DTO没实现Serializable。

解决方案有三种：

第一，给缓存对象实现Serializable接口，并保证所有字段都可序列化。

第二，把value直接存JSON字符串，比如用Jackson或Gson序列化，简单粗暴，还能避免对象引用被外部修改。

第三，如果确认业务不会修改缓存里的同一个对象实例，可以显式设置setStoreByValue(false)，改成存引用。但这样做风险很大，一旦调用方误改了对象，缓存里的数据也跟着变。

我的建议是：如果是“缓存数据”就用序列化副本，如果是“本地内存态共享数据”再用引用，不要混用。

4.2 过期策略和定时预热节奏不匹配

有一段时间我定时任务设的是每5分钟刷新一次，但缓存过期时间设的是1小时，导致缓存里数据很长时间都不会真正更新，看到的大概率是旧数据。

反过来也有问题：过期时间只有30秒，定时刷新周期却是1小时，那这1小时内大部分请求都打在数据库上，预热形同虚设。

这里的经验是：定时刷新周期至少要小于缓存过期时间的二分之一。比如缓存2小时过期，就每30分钟或1小时刷新一次。既留出足够余量对抗数据库抖动，又不会让数据太旧。

另外，Duration.ONE_HOUR是javax.cache.expiry.Duration，不是java.time.Duration，别引错包。

4.3 多实例同时预热：用JCache也能做分布式锁

生产环境很少有单实例，一旦多台机器同时启动，预热任务会在每台机器上都执行一遍，数据库直接被查爆。我见过最夸张的一次，8台实例同时启动，预热接口的数据库QPS瞬间到几千。

最简单的控制方式就是引入分布式锁。但这里有个小技巧：不一定要额外引入Redis，直接用JCache的putIfAbsent就能实现一个轻量级的锁。

java复制Cache<String, String> lockCache = ...; // 单独建一个短过期时间的cache
String nodeId = UUID.randomUUID().toString();
String lockKey = "warmup:lock:userCache";

boolean acquired = lockCache.putIfAbsent(lockKey, nodeId);
if (acquired) {
    try {
        userCacheWarmup.warmUp();
    } finally {
        lockCache.remove(lockKey, nodeId);
    }
}

putIfAbsent能保证只有第一个写入成功的实例拿到锁。释放时用remove(key, value)，并且value传自己的nodeId，防止误删别人的锁。锁条目可以配置一个较短的过期时间，比如30秒，这样即使持有锁的实例崩溃，锁也会自动释放，不会死锁。

当然，如果公司已经有统一的Redis分布式锁组件，直接用那个也行。面试里主动提到“JCache的putIfAbsent也能做分布式锁”，是很加分的细节。

4.4 预热失败不能拖垮应用启动

还有一个特别容易犯的错误：启动时候执行预热，直接把异常抛出去，导致整个应用启动失败。有一次我把预热逻辑放在ApplicationRunner里，结果数据库连接池还没就绪，查询直接超时，应用直接启动失败，线上事故。

后来我改成这种写法：

java复制@Override
public void run(ApplicationArguments args) {
    try {
        userCacheWarmup.warmUp();
    } catch (Exception e) {
        log.error("userCache warmup failed, will retry in background", e);
        asyncRetry();
    }
}

预热的定位应该是“尽力而为”的优化，不是“不做就挂”的强依赖。跑失败了不能阻塞主流程，应该记录下来，然后交给定时任务去重试，或者依赖Read-Through机制在请求进来时兜底。这样既保证了启动的稳定性，又不牺牲预热的收益。

5. 面试这么答，稳了

5.1 三步答题法

面对“如何通过JCache API实现一个简单的缓存预热逻辑”这道题，我建议你按三步走，条理清晰：

第一步，先点出预热的意义：解决冷启动缓存为空的问题，避免突发流量直接打到数据库。

第二步，介绍JCache API的核心对象：通过Caching.getCachingProvider()拿到Provider，再获取CacheManager，创建Cache，最后调用putAll批量写入。

第三步，给出关键代码，并且主动讲两个细节：一是putAll的性能优势，二是多实例场景下防止重复预热。

代码不必写全，画出核心骨架就行：

java复制CachingProvider provider = Caching.getCachingProvider();
CacheManager cacheManager = provider.getCacheManager();
Cache<String, String> cache = cacheManager.getCache("userCache", String.class, String.class);
if (cache == null) {
    MutableConfiguration<String, String> config = new MutableConfiguration<>();
    config.setTypes(String.class, String.class);
    config.setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(Duration.ONE_HOUR));
    cache = cacheManager.createCache("userCache", config);
}
Map<String, String> hotData = loadHotData(); // 从DB/RPC加载
cache.putAll(hotData);

这个回答，既覆盖了API使用，也提到了预热的核心流程，面试官没法挑出太大毛病。

5.2 六个高频追问，提前准备好

面试官大概率会往下追问，我整理了我见过的高频追问：

追问1：JCache和Redis什么关系？

JCache是缓存API规范，Redis是具体的缓存中间件。Redis客户端Redisson提供了JSR-107的实现，所以你可以通过JCache接口操作Redis，但大多数人直接用Spring Data Redis封装，两者不是同一个层次的概念。

追问2：CacheLoader和CacheWriter了解吗？

CacheLoader用于Read-Through场景，缓存miss时自动加载数据；CacheWriter用于Write-Through场景，写入缓存的同时同步写数据库。它们本质上是为“缓存与数据源保持一致”设计的扩展点。

追问3：putAll和循环put有什么区别？

putAll是批量语义，代码更清晰，实现层面有机会做批量优化；循环put更灵活，可以逐条处理失败、控制速率。但putAll不是原子的，大量数据时要分批。

追问4：多个实例同时启动怎么避免重复预热？

用分布式锁，保证只有一个实例执行预热。可以用Redis锁，也可以用JCache的putIfAbsent配合短过期时间实现轻量锁。

追问5：如果预热的数据量很大怎么办？

先评估是否真的全部需要预热，每天只看前100的商品就别把全量商品塞进去。如果确实需要大量预热，分页拉取、分批写入，并且放到异步线程池里执行，避免阻塞应用启动。

追问6：底层缓存从Ehcache换到Hazelcast，代码要改什么？

理论上业务代码只需要改依赖，javax.cache接口不用动。但要注意实现细节的差异，比如不同Provider的序列化要求、过期策略支持程度、是否支持分布式锁语义，这些需要回归测试。

5.3 把项目经验包装成加分故事

面试官更喜欢听到真实场景里的取舍，而不是干巴巴的概念。你可以提前准备一个属于你自己的预热故事，参考这个结构：

“我之前在项目里给订单维度的数据做过JCache预热。数据量大概20万条，放在MySQL里，查询接口压力比较大。我们的做法是：应用启动后用单独线程池异步加载，每次查5000条，分批写入缓存；缓存过期时间设2小时，定时任务每30分钟基于binlog变更记录做增量刷新。多实例部署时，用Redis分布式锁控制只有一个节点执行全量预热，其他节点等锁释放后直接读缓存。”

这段话里体现了数据量、批量策略、过期配置、多实例控制、全量加增量，每一个词都是面试官想听的。你不需要和我一模一样，只要把你的真实项目套进这个框架，效果不会差。

最后再分享一个我自己的习惯：不管面试还是做项目，遇到“缓存预热”我都会顺手看一眼缓存命中率监控。预热做得好的标准不是代码写得好看，而是上线后缓存命中率稳定在99%以上，数据库QPS明显下降。如果你能用数据证明预热的效果，比背多少API都管用。JCache这套规范本身不难，难的是把它放进真实生产环境里，还能从容应对各种意外。希望这篇能帮你在面试和实战中少走点弯路。