containsKey 比 get() + null 判断更合适，因其能准确区分“键不存在”和“键存在但值为 null”，避免误判缓存未命中；且不触发值构造或反序列化，线程安全，语义清晰。
Map.containsKey 为什么比 get() + null 判断更合适
在缓存场景中，用 containsKey 判断键是否存在，比先调用 get() 再判空更安全、更语义清晰。尤其当缓存值允许为 null（比如加载失败后显式存入 null 表示“该键确定不存在”）时，get(key) == null 无法区分“键不存在”和“键存在但值为 null”。而 containsKey 只关心键本身是否被映射，不受值内容影响。
常见错误现象：
— 缓存中存了 map.put("user:123", null)，后续用 map.get("user:123") == null 误判为“未命中”，导致重复加载
— 多线程下反复 get + put 造成不必要的对象创建或计算
Java HashMap 和 ConcurrentHashMap 的 containsKey 行为差异
HashMap.containsKey 是 O(1) 平均时间复杂度，底层直接走 hash 定位桶 + 遍历链表/红黑树查 key，不触发 value 的构造或反序列化；ConcurrentHashMap.containsKey 同样是只读操作，不会加全局锁，只在必要时锁定对应 segment 或 bin，适合高并发缓存场景。
- 如果缓存由单线程维护（如启动时预热），用
HashMap足够，内存开销略小 - 若缓存被多个请求线程读写（如 Web 应用的本地缓存），必须用
ConcurrentHashMap，否则containsKey可能抛ConcurrentModificationException或返回脏数据 - 注意：Guava Cache / Caffeine 等高级缓存已封装该逻辑，一般无需手动调
containsKey，除非你绕过它们直接操作底层 map
在 Spring @Cacheable 场景下，containsKey 基本用不上
Spring 的 @Cacheable 注解会自动处理键存在性判断、value 加载、空值处理（通过 CacheManager 配置的 Cache 实现）。你写的业务方法里不需要、也不应该手动对 Cache 对象调 containsKey —— 因为：
-
Cache接口不保证有containsKey方法（例如SimpleCache底层是ConcurrentHashMap，但EhCacheCache或RedisCache可能不暴露该能力） - Spring 已在拦截器中统一完成“查缓存 → 命中则返回 → 未命中则执行方法 → 存入缓存”全流程
- 强行在切面外调
containsKey会破坏缓存一致性，比如刚查完 key 不存在，另一线程就写入了，你却没感知
真要手写缓存逻辑时，containsKey 的典型用法
适用于轻量级本地缓存（无淘汰策略、无过期）、配置项缓存、枚举映射等静态或低频更新场景。关键点是：只查键，不取值，避免副作用。
Map<string user> userCache = new ConcurrentHashMap();
// ... 初始化或后台加载
if (userCache.containsKey("user:456")) {
// 确定 key 存在，再 get —— 这步可选，取决于是否需要值
User u = userCache.get("user:456"); // 此时 get 不会触发加载，只是引用获取
} else {
// 触发数据库查询或远程调用
User u = loadUserFromDB("456");
userCache.put("user:456", u);
}</string>
容易踩的坑：
— 用 TreeMap 代替 ConcurrentHashMap 做缓存，containsKey 退化为 O(log n)，且不支持并发读写
— 键对象未正确实现 equals / hashCode（比如用了未重写方法的自定义类作 key），导致 containsKey 总返回 false
— 忘记 map 初始化，直接调用 containsKey 抛 NullPointerException
缓存键的设计比怎么查更重要：确保键字符串唯一、无歧义、不带运行时敏感信息（如 session id），否则 containsKey 查得再快也没意义。
