containsValue() 方法底层是线性遍历，无哈希加速，必须逐个比较 value 的 equals()；因 Map 接口不保证 value 唯一，无法建立反向索引；小规模数据适用，大规模下性能远低于 containsKey()。
containsValue() 方法底层就是线性遍历
containsValue() 在 HashMap、LinkedHashMap、TreeMap 中都**没有哈希加速**，它必须逐个比较每个 value 是否满足 equals()。这不是设计缺陷，而是 Map 接口语义决定的：Key 有唯一性约束，Value 没有，无法建立反向索引。
常见错误现象：containsValue(true) 在一个含 10 万条目的 HashMap 上耗时 5–20ms（取决于 value 分布和 equals() 开销），而 containsKey("x") 基本稳定在纳秒级。
- 使用场景：仅适合小规模数据（
- 如果 value 是自定义对象，务必确认其
equals()和hashCode()实现正确且高效——否则性能雪上加霜 -
TreeMap.containsValue()还多一层O(n log n)的树节点遍历开销，比HashMap更慢
想查 value 又要快？得自己维护反向映射
没有银弹，但可以换结构：用额外空间换时间。典型做法是同步维护一个 HashSet<V> 或 Map<V, Boolean>（注意 value 类型需可做 key）。
示例：记录是否含某个状态值
立即学习“Java免费学习笔记（深入）”；
Map<String, Status> statusMap = new HashMap<>();
Set<Status> statusValues = ConcurrentHashMap.newKeySet(); // 线程安全可选
// 写入时同步更新
statusMap.put("task-1", Status.RUNNING);
statusValues.add(Status.RUNNING);
// 查 value 就变成 O(1)
boolean hasRunning = statusValues.contains(Status.RUNNING);
- 别直接用
new HashSet(statusMap.values())——这是快照，后续增删不反映 - 如果 value 可能重复（比如多个 key 对应同一个 value），就该用
Map<V, Integer>记频次，而非Set - 并发场景下，优先选
ConcurrentHashMap+computeIfAbsent等原子操作，避免手动加锁
误用 containsValue() 导致 CPU 暴涨的真实坑
线上曾见过定时任务每秒调用 containsValue() 检查缓存中是否存在某个 BigDecimal，而缓存 size 是 5000+，BigDecimal.equals() 又涉及位运算和 scale 比较——单次调用平均 0.3ms，积少成多直接拖垮服务。
- 错误模式：
while (map.containsValue(target)) { ... }—— 每次循环都全量扫一遍 - 兼容性陷阱：JDK 21 的
LinkedHashMap仍无优化；GraalVM AOT 编译也不改变行为 - 性能影响不是“有点慢”，而是「随数据量线性恶化」，压测时容易被忽略，上线后流量一涨就暴露
替代方案选型：要看你到底要什么
不是所有“查 value”都该用 containsValue()，先厘清真实意图：
- 检查是否存在某种状态？→ 改用状态枚举 + 单独布尔字段或专用状态集
- 想根据 value 找出所有 key？→ 预建
Map<V, List<K>>，但注意内存翻倍风险 - 只是临时判断，且数据真不大？→ 用
map.values().stream().anyMatch(...)语义更清晰，性能一样差，但至少意图明确 - value 是简单类型（String/Integer）且极少变更？→ 考虑用 Guava 的
BiMap（但 BiMap 不允许重复 value，适用面窄）
最常被忽略的一点：很多所谓“查 value”的需求，其实根源是模型设计偏了——Key 应该承载更多语义，而不是把业务逻辑塞进 Value 里再回头找。
