ConcurrentHashMap 的 computeIfAbsent 方法通过在哈希桶级别进行细粒度锁定，而不是锁定整个表，提供原子、安全的值计算。当提供给此方法的 mappingFunction 尝试在执行期间递归访问同一映射实例中的同一键时，会出现关键的重入危害，从而导致潜在的循环依赖。
在 Java 8 中，这种递归访问导致死锁，因为实现锁定了计算期间的特定哈希桶，而递归调用尝试获取当前线程已持有的相同锁。从 Java 9 开始，实现通过在计算期间向桶中插入一个 ReservationNode 占位符来检测这种递归，将其标记为“进行中”。如果同一线程在遍历同一键时遇到此 ReservationNode，该方法将抛出 IllegalStateException，并附带“递归更新”的消息，而不是导致死锁，从而提供关于无效递归的即时反馈。
这种快速失败机制防止了 ForkJoinPool 公共池和其他执行上下文中的线程饥饿和活性问题，而这些地方的死锁将是灾难性的。然而，它要求开发人员仔细构造计算逻辑，以避免键之间的循环依赖，通常需要在领域层中显式检测循环。
我们在一个高吞吐量的定价引擎中遇到了这个危害，该引擎缓存衍生品的计算，以避免冗余的蒙特卡洛模拟。缓存利用 ConcurrentHashMap<String, CompletableFuture<BigDecimal>> 及其 computeIfAbsent 方法，以确保相同的期权定价请求被去重复，并且每个市场数据滴答只计算一次。这个模式在异步数据加载场景中很常见，其中昂贵的计算必须在多个并发请求之间共享。
当计算复杂衍生品时，问题显现出来，尽管由于数据建模错误，无意中参考了同一缓存中的其他衍生品。具体而言，Instrument A 的定价公式将 Instrument B 作为基础，而 Instrument B 的公式意外地又引用了 Instrument A，形成了循环依赖。这导致对 A 的 computeIfAbsent 调用在值初始化阶段触发了另一个对 A 的 computeIfAbsent 调用。
我们首先考虑的解决方案是将缓存访问封装在粗粒度的 synchronized 块中，以防止计算期间的任何并发修改。虽然这种方法可以消除死锁风险，但它会将整个映射中所有的定价计算序列化，实际上将吞吐量降低到单线程 HashMap 的水平，破坏实时交易所需的性能特征。
第二种方法是使用 putIfAbsent，结合在映射操作之前通过 supplyAsync() 创建的预计算 CompletableFuture 实例。这可以避免在计算期间持有锁，但会急切地在键已经存在于缓存时发起昂贵的定价计算，浪费大量 CPU 资源于冗余计算，从而违背了缓存的目的。
我们的第三种解决方案实现了显式循环检测，维护一个 ThreadLocal<Set<String>>，包含“当前正在计算的键”，它在当前线程的调用栈中。在启动任何 computeIfAbsent 操作之前，系统会检查此集合中的目标键，在达到映射层之前对循环引用抛出 DomainException。这保持了 ConcurrentHashMap 的无锁并发性，同时提供了关于无效工具层次结构的有意义的业务上下文。
我们选择第三种解决方案，因为它解决了根本原因——无效的循环金融模型，而不是仅仅掩盖症状，同时完全保留了 ConcurrentHashMap 的并发性能特征。显式验证提供了清晰的审计轨迹，显示哪些特定工具形成了无效的循环依赖，使数据团队能够修复源数据错误，而不仅仅是避免崩溃。
该实现消除了生产上的 IllegalStateException 崩溃，并将冗余定价计算减少了约 40%，同时保持交易平台的亚毫秒延迟要求。显式的循环检测还通过强制纠正源头的错误工具层次结构来提高数据质量，而不是在代码中默默处理它们。
为什么 ConcurrentHashMap 拒绝 null 键和值而 HashMap 允许它们？
ConcurrentHashMap 将 null 用作其并发原子操作中的内部哨兵值，以区分“键不存在”和“计算进行中”。像 computeIfAbsent 和 merge 这样的操作依赖于这个哨兵，以在原子更新过程中明确指示缺失，而不需要额外的查找，这可能会造成竞争条件。由于 get 方法对缺失的键和映射到 null 的键都返回 null，允许 null 值将使得在并发修改期间很难确定一个键是否真正存在于映射中，从而打破复合操作的原子性保证。
Java 8+ 的桶级锁与 Java 7 的基于段的并发有什么不同？
Java 7 使用固定的 16 个段数组，每个段由独立的 ReentrantLock 保护，这人为地限制了最大写入并发为 16 个线程，无论可用硬件如何。Java 8+ 取消了这种分段，而是采用在单个哈希桶级别的细粒度锁定，通过对每个桶的第一个节点使用 synchronized 块，并结合无锁的 CAS 操作来处理无争用的写入和读取。这种架构使数千个线程能够在不同的桶上并发写入，而无需争用，同时调整操作使用渐进传输和 volatile 下一个表指针，以允许在迁移期间进行读取。
何时应该优先考虑 computeIfAbsent 而不是 putIfAbsent，以及须考虑哪些锁定隐患？
当值创建昂贵并且必须仅在键缺失时原子地发生时，computeIfAbsent 是必不可少的，因为它接受一个仅在必要时执行的 Function。然而，实现会在函数执行期间锁定整个哈希桶，这意味着运行时间长的计算将串行化所有对该桶哈希到的键的访问，可能会造成性能瓶颈。putIfAbsent 需要在调用之前预先计算值，意味着昂贵的创建无论键的存在与否都发生，但只在简单插入检查期间保持锁定，使其在值创建便宜或幂等时变得更可取。