concurrentHashMap源码中的readValueUnderLock(e)存在的意义?
concurrentHashMap
源码(JDK1.6)get
方法中为什么要readValueUnderLock(e)
,v
为null
究竟是怎么产生的?put
方法中有这么一段:tab[index] = new HashEntry<K,V>(key, hash, first, value);
难道在执行构造方法中会存在中间状态?value
还没有赋值就能读到?
V get(Object key, int hash) {
if (count != 0) { // read-volatile
HashEntry<K,V> e = getFirst(hash);
while (e != null) {
if (e.hash == hash && key.equals(e.key)) {
V v = e.value;
if (v != null)
return v;
return readValueUnderLock(e); // recheck
}
e = e.next;
}
}
return null;
}
V readValueUnderLock(HashEntry<K,V> e) {
lock();
try {
return e.value;
} finally {
unlock();
}
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
前面这一句说明了表里有这个
key
的,你看看put
方法,当value
为null
的时候是会跑出异常的:我这是高版本的,可能和你的不一样,但是也是值也是不能为空的。
所以:
不为空可以直接返回,如果为空则说明有其他线程在操作它。所以就加了一句。
现在版本的
get
方法把HashEntry<K,V> e
弄成UNSAFE.getObjectVolatile()
获取,像是volatile
的了楼主可以把JDK升级一下,我用的
1.8
找了一下,没发现这段代码在ConcurrentHashMap
中。对象初始的时候就是null,这个null并不是在程序中特意赋值的。