递归 ConcurrentHashMap.computeIfAbsent() 调用永远不会终止。错误还是“功能”？

Question

前段时间，I've blogged about a Java 8 functional way of calculating fibonacci numbers recursively，带有ConcurrentHashMap 缓存和新的有用的computeIfAbsent() 方法：

import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

public class Test {
    static Map<Integer, Integer> cache = new ConcurrentHashMap<>();

    public static void main(String[] args) {
        System.out.println(
            "f(" + 8 + ") = " + fibonacci(8));
    }

    static int fibonacci(int i) {
        if (i == 0)
            return i;

        if (i == 1)
            return 1;

        return cache.computeIfAbsent(i, (key) -> {
            System.out.println(
                "Slow calculation of " + key);

            return fibonacci(i - 2) + fibonacci(i - 1);
        });
    }
}

我选择ConcurrentHashMap 是因为我正在考虑通过引入并行性（我最终没有这样做）来使这个示例更加复杂。

现在，让我们将数字从8 增加到25 并观察会发生什么：

        System.out.println(
            "f(" + 25 + ") = " + fibonacci(25));

程序永远不会停止。在方法内部，有一个永远运行的循环：

for (Node<K,V>[] tab = table;;) {
    // ...
}

我正在使用：

C:\Users\Lukas>java -version
java version "1.8.0_40-ea"
Java(TM) SE Runtime Environment (build 1.8.0_40-ea-b23)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

Matthias, a reader of that blog post also confirmed the issue (he actually found it).

这很奇怪。我会期待以下两种中的任何一种：

• 有效
• 它会抛出一个ConcurrentModificationException

但只是从不停止？这似乎很危险。它是一个错误吗？还是我误解了某些合同？

Answer 1

这当然是一个“功能”。 ConcurrentHashMap.computeIfAbsent() Javadoc 内容如下：

如果指定的键尚未与值关联，则尝试使用给定的映射函数计算其值并将其输入到此映射中，除非为空。整个方法调用以原子方式执行，因此每个键最多应用一次该函数。在计算过程中，其他线程对该映射的某些尝试更新操作可能会被阻止，因此计算应该简短且简单，不得尝试更新此映射的任何其他映射 。

“不得” 措辞是一个明确的约定，我的算法违反了它，尽管不是出于相同的并发原因。

有趣的是没有ConcurrentModificationException。相反，程序永远不会停止 - 在我看来这仍然是一个相当危险的错误（即infinite loops. or: anything that can possibly go wrong, does）。

注意：

HashMap.computeIfAbsent() 或Map.computeIfAbsent() Javadoc 不禁止这种递归计算，这当然是荒谬的，因为缓存的类型是Map<Integer, Integer>，而不是ConcurrentHashMap<Integer, Integer>。子类型彻底重新定义超类型合同是非常危险的（Set vs. SortedSet 是问候）。 因此也应该禁止在超类型中执行这种递归。

Answer 2

这已在JDK-8062841 中修复。

在2011 proposal 中，我在代码审查期间发现了这个问题。 JavaDoc 已更新并添加了临时修复。由于性能问题，它在进一步的重写中被删除。

在2014 discussion 中，我们探索了更好地检测和失败的方法。请注意，为了考虑低级别的更改，一些讨论已离线发送到私人电子邮件。虽然不能涵盖所有情况，但常见情况不会活锁。这些 fixes 在 Doug 的存储库中，但尚未进入 JDK 版本。

Answer 3

这与错误非常相似。 因为，如果您创建容量为 32 的缓存，您的程序将一直运行到 49。 有趣的是，参数 sizeCtl =32 + (32 >>> 1) + 1) =49！ 可能是调整大小的原因？