前言
JDK8的ConcurrentHashMap并不是完美的,从https://bugs.openjdk.java.net/projects/JDK/issues上也可以看到JDK的很多Bug,当然,通过给concurrency-interest发邮件也可以和Doug Lea直接对话。
最重要的是,知道了这些bug的存在,可以避免我们去分析这些不正确的代码的“正确性”。
构造器
public ConcurrentHashMap(int initialCapacity) {
if (initialCapacity < 0)
throw new IllegalArgumentException();
int cap = ((initialCapacity >= (MAXIMUM_CAPACITY >>> 1))
MAXIMUM_CAPACITY :
tableSizeFor(initialCapacity + (initialCapacity >>> 1) + 1));
this.sizeCtl = cap;
}
这里的initialCapacity + (initialCapacity >>> 1) + 1
其实是一个bug,正确的做法应该是下面这个构造器的做法。
public ConcurrentHashMap(int initialCapacity,
float loadFactor, int concurrencyLevel) {
if (!(loadFactor > 0.0f) || initialCapacity < 0 || concurrencyLevel <= 0)
throw new IllegalArgumentException();
if (initialCapacity < concurrencyLevel) // Use at least as many bins
initialCapacity = concurrencyLevel; // as estimated threads
long size = (long)(1.0 + (long)initialCapacity / loadFactor);
//获得cap的正确做法
int cap = (size >= (long)MAXIMUM_CAPACITY) ?
MAXIMUM_CAPACITY : tableSizeFor((int)size);
this.sizeCtl = cap;
}
主要问题在于,两个构造器的行为不一致,即使第一个构造器传入(16)
、第二个构造器传入(16, 0.75f, 1)
,最终table的长度是不一样的。
sizeCtl
这个bug在helpTransfer
和addCount
中都有,主要对sizeCtl
的临时变量的判断有问题。
它们都有这样一个判断sc == rs + 1 || sc == rs + MAX_RESIZERS
,其中sc
是获得了sizeCtl的临时变量,rs
是一个与容量唯一对应的一个标签值(它占sizeCtl的高16bit)。所以应该这样写:sc == (rs << RESIZE_STAMP_SHIFT) + 1
、sc == (rs << RESIZE_STAMP_SHIFT) + MAX_RESIZERS
。
扩容部分的sweep recheck
在transfer
的函数实现中,最后一个线程来归还sizeCtl的线程数时,需要从尾到头再检查一遍每个哈希桶是否都完成了转移,但这没有必要的。
Doug Lea也说了,这个sweep扫查机制是之前版本遗留下来的,本来是可以删除掉的。
删除掉没有任何影响,因为当最后一个线程来归还许可时,这意味着其他线程已经归还了许可。且只有在当前线程 完成了领取的任务后,才会归还许可,所以当最后一个线程来归还许可时,每个哈希桶都已经完成了转移,所以说最后的sweep检查是没有必要的。
看以后有时间,按照Request for Enhancement提个issue吧。
computeIfAbsent
当你执行这段代码时:
Map<String, Integer> map = new ConcurrentHashMap<>(16);
map.computeIfAbsent("AaAa", key -> {
return map.computeIfAbsent("BBBB", key2 -> 42);
});
会发生无限循环。
过程如下(我们以左框距离代表调用深度):
- 第一次调用
computeIfAbsent
,参数是"AaAa"
。第一次循环创建table,第二次循环将索引处从null设置为一个ReservationNode,第二次循环中,紧接着递归调用computeIfAbsent
。- 第二次调用
computeIfAbsent
,参数是"BBBB"
。第一次循环,发现该索引处(获得的是同一个索引)是一个ReservationNode,if (binCount != 0)
分支没有进入,循环继续。一直重复这个循环。
- 第二次调用
后记
ConcurrentHashMap的bug其实不少,大家阅读源码时不要觉得源码就一定是正确的。另外,给一下JDK提bug的链接,以后有机会给JDK提提Bug,不过提之前先搜搜看是否有人已经提过了。