最近发现java 1.8的concurrentHashMap，在使用computeIfAbsent时，如果涉及修改map，则会产生bug。
示例代码如下：
System.out.println("start.");
map.computeIfAbsent("t",
(String t) -> map.computeIfAbsent("t", (String i) -> "i")); //halt在这里
System.out.println("fin.");
如果执行这段代码，你会发现代码会停在注释出，一直没有结果。
最开始以为是递归实现的问题，通俗的说，就是在构造一个函数的时候陷入了自递归。就是你想构造一个A，但是A的构造依赖A已完成构造后的某些属性。为了验证是否是这个原因，我们把代码做一些调整，消除递归调用。
ConcurrentHashMap map = new ConcurrentHashMap<>();
System.out.println("start.");
map.computeIfAbsent("t",
(String t) -> {
map.put("t", "t");
return "t";
});
System.out.println("fin.");
你会发现，代码继续停在哪里，无法输出"fin."。
然后怀疑是死锁，怀疑concurrentHashMap使用了非可重入锁。但是跟着看conrrentHashMap的实现，发现是基于cas + synchronized的方式实现，而synchronized本身是可重入的，因此这里不满足死锁的条件。
继续看concurrentHashMap的注释，里面有这样一句话：
/*
must not attempt to update any other mappings of this map.
*/
这句话确定了这个问题应该是已知存在的。
所以应该绝对避免在computeIfAbsent中有递归，或者修改map的任何操作。
为了搞清楚原因，我们继续debug concurrentHashMap的源码，发现这种在computeIfAbsent中，如果尝试修改map的情况下，代码会在
for (Node[] tab = table;;) { //无限循环
Node f; int n, i, fh;
if (tab == null || (n = tab.length) == 0)
tab = initTable();
else if ((f = tabAt(tab, i = (n - 1) & h)) == null) {
Node r = new ReservationNode();
synchronized (r) {
if (casTabAt(tab, i, null, r)) { //cas
....
中反复循环。
我尝试通俗的解释一下这个问题：
注：不见得正确，只是个人理解
由于concurrentHashMap中使用的是cas操作，因此在出现cas嵌套的情况下，就会形成一种『死锁』。举例来说，一个值原来是 1， 我想把它修改成2，正常的cas操作，会比较在修改的那一刻，值是否仍然为1。这种比较，在cas只有一层的情况下，是没有问题的。但是，假如有两层cas，这个值原来是1，第一层把 1 -> 2，在cas还没有生效时，继续进入第二层cas操作，把 2 -> 3，当最终提交时，第二层cas比较当前值是否是2，但由于当前指仍然是1，因此修改无效。最终反复进入循环，形成死锁。
虽然computeIfAbsent的代码注释中对这种修改map的行为做了强提示，但在实际中，我认为这种行为仍旧是concurrentHashMap的一个实现bug。
https://bugs.openjdk.java.net/browse/JDK-8172951
好在这个问题在java 1.9中已经基本修复了。
This is fixed in JDK 9 with JDK-8071667 . When the test case is run in JDK 9-ea, it gives a ConcurrentModification Exception.
java 9