企业官网建设流程全解析

后台总有读者在准备Java面试，问得比较多的一道"基础篇"题目就是今天要聊的：JCache（JSR-107）中 Cache 接口的 put 和 get 方法，在键不存在时到底是什么行为。题目确实只有一句话，但这句话背后牵出的知识点一点都不基础。我在面试候选人时，十个人里差不多只有三四个能答对一半，能完整讲清规范语义、读穿透（read-through）和 null 约束的人就更少了。这篇就把这道题彻底拆开，从规范到实现，从标准答案到项目里的真实避坑，一次说透。

无论你是正在冲刺 Java 后端岗位的候选人，还是已经在用 Caffeine、Ehcache、Redis 但没认真读过 JCache 标准的开发者，这篇都值得看完。因为这个问题的妙处在于：它看起来是 API 的"查字典题"，实际上考的是你能否读懂标准接口背后的设计意图，以及能否把规范语义迁移到真实的高并发缓存场景中。

1. 这道"键不存在"的题，到底在考什么

1.1 JCache在Java生态中的位置

先说清楚 JCache 是什么。JSR-107 是 Java 官方的缓存 API 规范，对应的包名是javax.cache，核心接口就是javax.cache.Cache<K, V>。很多开发者知道 Spring Cache、知道 Caffeine、知道 Ehcache，但对 JCache 的印象反而比较模糊，这是很可惜的，因为它是 Java 生态里唯一的缓存标准抽象。

它的定位有点像 JDBC：你写的代码只依赖标准接口，底层实现可以随时切换。Ehcache 3 实现了 JCache，Hazelcast、Infinispan 实现了 JCache，Caffeine 官方也提供了 JCache 适配器，Spring Cache 同样支持把 JCache 作为底层 provider。也就是说，一旦你掌握了javax.cache.Cache的语义，你就在不同缓存产品之间拥有了一套"通用语言"。

面试官考这道题，恰恰是因为它属于"标准接口"的知识。初级工程师往往只看方法名，认为get就是查一下、put就是塞进去，忽略了标准接口的文档里其实定义了一堆实现细节。而这些细节，直接决定你在生产环境会不会写出有隐患的缓存代码。

1.2 从Map思维到Cache思维的关键转变

我面试时发现，答错这道题的人，多半是把javax.cache.Cache直接等同于java.util.Map来理解了。这个思维惯性是最大的坑。

java.util.Map是数据结构，javax.cache.Cache是带策略的组件。两者在行为上有几个非常关键的差异：

从 Map 思维到 Cache 思维，核心是理解"键不存在"不是一个静态事实。在 JCache 里，一个键"不存在"可能有几种情况：从来没写过、写过但已过期、被 LRU 等驱逐策略移除、在分布式环境下还没同步过来。所以面试官问"键不存在时行为是什么"，其实是在试探你能不能意识到这层复杂性。

2. 键不存在时 get 返回什么：规范和直觉的差距

2.1 规范语义：返回 null，不抛异常

先给最直接的结论：根据 JCache 规范，Cache.get(K key)在键不存在时返回null，并且不会抛异常。

Cache<String, String> cache = createCache(); String value = cache.get("key-does-not-exist"); System.out.println(value); // 输出 null，JDK 层面不会抛任何异常

这个行为看起来和Map.get一样，但有一个前提条件：传入的 key 本身不能是 null。如果调用cache.get(null)，规范要求实现必须抛出NullPointerException。这一点很多面试者会漏掉。

那这个null该怎么理解？它代表的是"未命中"，不是"出错"。缓存命中与否是一种正常状态，所以用返回值表达，而不通过异常表达。这是我特别想强调的一点：良好的接口设计会把"正常但没结果"和"异常"分开，null是前者，CacheException才是后者。如果面试官问"get 未命中会不会抛异常"，答案是不会，除非底层缓存本身出问题了。

2.2 read-through 模式下，get 可能悄悄触发加载

这里是最容易和Map.get拉开差距的地方。JCache 支持一种叫读穿透（read-through）的配置：当你创建缓存时指定了CacheLoader，并且把ReadThrough配置设为 true，那么在get未命中时，Cache 实现会自动调用你配置的 loader 去加载数据。

调用链大致是这样的：

1. 应用层调用cache.get(key)；
2. Cache 实现先在自身存储中查找；
3. 命中，直接返回 value；
4. 未命中，检查配置：若支持 read-through，则调用CacheLoader.load(key)；
5. loader 返回非 null，把它写入缓存并返回该值；
6. loader 返回 null，则get返回 null，且不对 null 做缓存。

这意味着什么？意味着一个看起来只读的get，在未命中时可能悄悄发起一次数据库查询或远程接口调用。流量稍大，这就是缓存穿透的温床。

我在项目里就踩过类似的坑。排查一个接口的数据库压力时，发现某个热点数据的缓存明明很少命中，日志里却频繁出现穿透查询。翻代码才发现当时为了方便，把所有 key 都放进了 read-through 缓存里，结果每个未命中请求都会打一次 DB。后来优化方案是把热点 key 的加载逻辑改成显式控制，而不是完全依赖 get 去触发 loader。

所以回答这道题时，如果你能主动补一句"如果配置了 read-through，get 在未命中时会尝试加载，加载不到才返回 null"，面试官眼里你的水平会立刻不一样。

2.3 getOrDefault 与 containsKey 的正确使用姿势

Cache接口还提供了一个 default 方法：V getOrDefault(K key, V defaultValue)。因为 JCache 不允许 null value，它的语义和Map.getOrDefault很接近，实现基本是：

V value = get(key); return value != null ? value : defaultValue;

但它内部照样走的是get，也就是说，如果配置了 read-through，getOrDefault一样可能触发 loader。如果你只是想知道"这个 key 有没有值"，不想额外加载，那应该用containsKey。

if (cache.containsKey(key)) { // 只判断存在性，不会触发 CacheLoader }

一个小建议：在需要"拿值"和"判断是否存在"两种场景交错出现时，优先考虑能否在一次get内解决，避免先containsKey再get的两次访问。比如你要做一个"不存在则加载"的逻辑，直接用get判断 null 更高效；但如果你的本意是"只要没有就返回默认值，不要打扰底层存储"，那就用containsKey配合默认逻辑。

3. put 方法在键不存在时返回什么：这里才有真正的坑

3.1 第一层答案：put 在键不存在时返回 null

再来回答 put 的部分。Cache.put(K key, V value)也是一个很直接的定义：把 key 关联到 value，如果这个 key 之前已经有映射，旧值会被替换；如果之前没有映射，put 返回null。

String previous = cache.put("order:1001", "PAID"); // key 不存在时，previous = null，表示之前没有旧值 String previous2 = cache.put("order:1001", "REFUNDED"); // key 存在时，按规范语义，previous2 应该是 "PAID"

和 get 一样，key 为 null 或者 value 为 null 都会抛NullPointerException。正因为 JCache 不允许 null value，所以 put 返回 null 在这里是"无歧义"的：它不会出现 Map 里那种"旧值本来就是 null，得靠 containsKey 区分"的尴尬。

3.2 规范允许 put"偷懒"：返回值可能是 best-effort

这是整道题里区分度最高、也最容易被人忽略的细节：JCache 规范对 put 的返回值并不是强保证。

什么意思？从javax.cache.Cache的接口语义来看，put 方法确实"应当"返回旧值，但规范同时允许实现出于性能原因选择不返回旧值，此时实现会返回 null。也就是说，put 返回 null 可能表示"没有旧映射"，也可能表示"有旧映射，但实现没帮你取回来"。

我见过不少开发者把 put 的返回值当成业务判断依据，比如：

String oldStatus = cache.put(key, newStatus); if (oldStatus == null) { // 想当然地认为这是第一次写入，于是去执行某些初始化逻辑 }

在 HashMap 上这么做没问题，在 JCache 的某些实现上，oldStatus 可能恰好是 null，而实际 key 早已存在。这种代码要是跑到生产环境，大概率会在并发场景下埋一个很隐蔽的 bug。

那为什么规范要留这个口子？核心是性能。对一个分布式缓存来说，put 时顺便把旧值带回来，可能需要额外的网络往返或序列化成本；对一些内存型实现来说，返回旧值可能又涉及拷贝。规范允许实现"量力而行"，把精准性留给了另一个方法。

3.3 getAndPut 与 putIfAbsent：把不确定变成确定

如果你确实需要"拿到旧值并写入新值"的原子语义，JCache 提供了专门的getAndPut：

User previous = cache.getAndPut("user:" + userId, updatedUser); // 这里拿到的 previous 才是被承诺的旧值

getAndPut的定位就是原子地执行"返回旧值 + 设置新值"，它不像 put 那样允许实现偷懒。所以规范的建议很明确：业务上需要依赖旧值做判断时，别用 put，用 getAndPut。

另一个高频方法是putIfAbsent，它只在 key 不存在时才写入，并且返回 boolean 表示是否写入成功：

boolean firstWrite = cache.putIfAbsent("coupon:" + couponNo, user) ; if (firstWrite) { // 说明这次抢券是第一个成功的 } else { // 说明别人已经先写入了，做冲突处理 }

这三个方法放一起看，逻辑就非常清晰了：

4. 不同 JCache 实现下的行为差异与答题模板

4.1 从实际接触到的实现看"方言"差异

标准接口最怕的就是"每个实现都有自己的脾气"。从我的实际观察来看，Ehcache 3、Hazelcast、Infinispan、Caffeine 的 JCache 适配器等主力实现，整体都遵循规范，但在 put 返回旧值这个细节上的策略并不完全一致。

这不是说哪个实现做错了，而是规范给了空间。内存型实现返回旧值的成本相对低，实现方自然会去补全这个语义；分布式缓存返回旧值可能意味着一次额外的跨节点读取，实现方就更有动力把 put 的返回值做成"尽力而为"。这也正好印证了 3.2 节说的：千万不要把 put 的返回值当作跨实现的可靠约定。

我在做技术选型时，一般会这样判断：如果缓存只承载"加速读"的职责，写入方根本不在乎旧值，那用 put 完全没问题；如果缓存参与了业务流程的状态判断，比如要判断"是不是第一次写入"，那就无条件改用getAndPut或putIfAbsent，把对实现策略的依赖降到零。标准接口的最大价值是让你在不同实现之间平滑迁移，而不是让你赌某个实现会给你什么额外保证。

4.2 面试回答模板：三段式把分数拿满

很多读者问我有没有可以直接背的回答方式。我建议按下面这个三段式来组织，既简洁又有层次。

第一句，直接给契约结论：

get 在键不存在时返回 null，不抛异常；put 在键不存在时返回 null，表示之前没有旧映射。

第二句，给规范层面的补充：

但 put 的返回值不是强保证，JCache 规范允许实现出于性能原因不返回旧值，所以如果业务需要精确拿到旧值并更新，应该用 getAndPut，而不是依赖 put 的返回值。

第三句，给加分项：

另外，JCache 不允许 null key 和 null value，传 null 会抛 NullPointerException；如果缓存配置了 read-through，get 在未命中时还可能触发 CacheLoader 加载，加载不到才会返回 null。

这样回答下来，从结论到细节再到延伸，面试官基本能判断你是真的理解了这个标准，而不是背了两行 API 文档。

4.3 由这道题引出的其他接口行为

这类基础题经常被面试官顺势延伸。比如containsKey在键不存在时返回 false，并且它不会触发 read-through 加载；remove(K key)在键不存在时返回 false，不会抛异常；clear()清空缓存后，所有 get 都会返回 null。这些行为在规范里都遵循同一个设计原则：正常状态通过返回值表达，key 为 null 才走异常路径。

还有更深入的invoke和CacheEntryProcessor，可以在缓存内执行原子操作，避免"先 get 再 put"的竞态。如果你已经能聊到这里，说明你对 JCache 的理解已经超出大部分候选人了。不过这些属于进阶玩法，面试基础篇通常不需要展开太深。

5. 高频追问与项目里的真实避坑

5.1 高频追问速查表

我把这道题相关的追问和答案要点整理成了表格，背熟它，面试足够用了。

5.2 实战：JCache 不能存 null，缓存穿透怎么处理

项目里最常见的连锁问题是这样的：业务查库，结果为 null，本来想把 null 缓存起来避免下次再查，结果发现 JCache 不支持 null value，直接抛异常。于是代码往往退化成"只有非 null 才写缓存"，结果就是那个导致 null 的 key 永远穿透到数据库。

我常用的一个方案是定义占位对象，把"查无此值"也变成一个可缓存的标记。比如：

public final class NullMarker { public static final NullMarker INSTANCE = new NullMarker(); private NullMarker() {} }

写入时这样处理：

Object value = cache.get(key); if (value == null) { User user = userMapper.findById(id); if (user != null) { cache.put(key, user); } else { cache.put(key, NullMarker.INSTANCE); } } else if (value instanceof NullMarker) { // 说明之前已经查过，结果是"不存在" return null; } else { return (User) value; }

这种方案的代价是 value 的类型被"污染"了，要么把泛型放开为 Object，要么在业务层再做一层封装。如果项目里这种空值缓存需求很多，我倾向于包装一个CacheResult<T>之类的结构体，显式区分"命中数据""命中空标记""未命中"三种状态，比散落的 NullMarker 更好维护。

对于热点高并发场景，还可以在缓存前面加布隆过滤器做第一层拦截，但布隆过滤器有误判率，而且维护成本不低，我会谨慎使用。占位对象方案虽然朴素，却足够通用，也不需要额外组件。

5.3 我的面试观察与最后建议

这道题我自己在面试中会当作"梯度测试"来用。能答出第一层结论的人，说明对 API 有基本记忆；能主动提到 put 返回值可能不精确、推荐用 getAndPut 的人，说明读过规范且踩过坑；能再补一句 key 为 null 会抛 NPE、read-through 会影响 get 行为的人，基本可以放进"对缓存有体系化理解"的池子里了。

我不太建议为了面试去死记硬背这一段回答，因为你只要真的用 JCache 写过一两个带 CacheLoader 的缓存，再在并发环境里被 put 的返回值坑过一次，这些细节自然就刻在脑子里了。阅读规范文档的习惯比背 API 重要得多。下次再遇到类似"键不存在时行为是什么"的问题，试着先想三件事：返回值表达什么、异常表达什么、配置会不会改变默认行为。想通这三个维度，面试官无论怎么追问，你都能站得住。