ConcurrentHashMap的containsKey对已存在UUID返回false的原因排查

问题背景 #

我使用Map<Long, Map<UUID, OperationEntry>> stepOperations = new ConcurrentHashMap<>()管理操作执行流程，Kafka消息处理器（由16线程的线程池处理）收到操作状态变更消息时，需要根据传入的UUID查找并更新stepOperations中的记录状态。使用的是标准java.util.UUID类（未重写），截图显示某UUID（如3102869c-7653-4fb7-ad47-a629b5cbac90）明明存在于Map中，但containsKey方法返回结果不符合预期。

问题代码 #

private OperationEntry getOperationLogEntry(UUID requestId) {
    return stepOperations.values().stream()
        .filter(value -> value.containsKey(requestId))
        .map(value -> value.get(requestId))
        .findFirst()
        .orElse(null);
}

另外，以下简单测试代码运行符合预期：

Map<UUID, String> testMap = new java.util.concurrent.ConcurrentHashMap<>();
UUID key = UUID.randomUUID();
testMap.put(key, "testValue");
if (testMap.containsKey(key)) {
    System.out.println(testMap.get(key));
}

问题分析与解决方案 #

• 内层Map的线程安全性是核心诱因：外层使用了线程安全的ConcurrentHashMap，但如果内层Map是普通HashMap，在多线程并发读写时会出现数据结构损坏（比如哈希表的链表/红黑树结构异常），直接导致containsKey无法正确识别已存在的键。
• UUID本身无问题：标准java.util.UUID的equals和hashCode方法实现正确，测试代码中用ConcurrentHashMap作为内层Map能正常工作，也验证了这一点。
• 修复方案：
  1. 确保内层Map也采用线程安全实现：往stepOperations中插入内层Map时，创建new ConcurrentHashMap<>()而非普通HashMap。
  2. 优化查找逻辑：如果能通过外层的Long键直接定位到目标内层Map，避免遍历所有values，既能提升性能，也能减少并发场景下的遍历冲突。
  3. 注意ConcurrentHashMap的弱一致性迭代：遍历外层Map的values时，弱一致性迭代可能看不到最新插入的内层Map，但不会导致已存在的内层Map出现键无法匹配的问题，因此核心仍聚焦内层Map的线程安全。

内容的提问来源于stack exchange，提问作者itnick