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

Question 1

前段时间，我写了一篇关于Java 8函数式递归计算斐波纳契数的方法，其中包括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也确认了这个问题（他实际上找到了）。

真奇怪我本来预期以下两个：

有用
它抛出一个 ConcurrentModificationException

但是，永不停止？那似乎很危险。是虫子吗？还是我误会了一些合同？

Question 2

这在JDK-8062841中已解决。

在2011年的提案中，我在代码审查过程中发现了这个问题。JavaDoc已更新，并添加了临时修复程序。由于性能问题，在进一步重写中将其删除。

在2014年的讨论中，我们探索了更好地检测和失败的方法。请注意，一些讨论已脱机到私人电子邮件中，以考虑低级更改。尽管并非每种情况都可以涵盖，但常见的情况不会自动生效。这些修复程序位于Doug的存储库中，但尚未纳入JDK版本。

Question 3

这当然是一个“功能”。该ConcurrentHashMap.computeIfAbsent()Javadoc中写道：

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

在“绝不能”字眼是一个明确的合同，我的算法侵犯，尽管不是相同的并发原因。

仍然有趣的是，没有ConcurrentModificationException。相反，该程序永远不会停止-在我看来，这仍然是一个相当危险的错误（即无限循环。或者：可能会出错的任何事情都会发生）。

注意：

该HashMap.computeIfAbsent()或Map.computeIfAbsent()的Javadoc不禁止这种循环的计算，这当然是可笑的高速缓存的类型Map<Integer, Integer>，不是ConcurrentHashMap<Integer, Integer>。对于子类型来说，彻底重新定义超级类型合同是非常危险的（Set相SortedSet对于问候）。因此，在超级类型中也应禁止执行此类递归。

Question 4

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