java - ConcurrentHashMap的get为什么可以不加锁?

Answer 1

1. 内部实现用了锁，你用它的时候就不需要再加一层锁了

       『他都是复制出一个新的数组进行复制, 而非在原地操作』 你在哪里看到有复制的代码？

   2/3. 写入没完成的时候就读，就会读到null，此时锁是被写操作lock的，等待写操作unlock，再去读就可以读到了。

Answer 2

1. get 无需加锁，只是读取并不会对数据发生改变get 无需加锁，只是读取并不会对数据发生改变

2. readValueUnderLock 正常情况不会被执行

3. e.value 不会为 null 作者Doug Lea解释如下

Not quite. You are right that it should never be called. However, the JLS/JMM can be read as not absolutely forbidding it from being called because of weaknesses in required ordering relationships among finals vs volatiles set in constructors (key is final, value is volatile), wrt the reads by threads using the entry objects. (In JMM-ese, ordering constraints for finals fall outside of the synchronizes-with relation.) That's the issue the doc comment (pasted below) refers to. No one has ever thought of any practical loophole that a processor/compiler might find to produce a null value read, and it may be provable that none exist (and perhaps someday a JLS/JMM revision will fill in gaps to clarify this), but Bill Pugh once suggested we put this in anyway just for the sake of being conservatively pedantically correct. In retrospect, I'm not so sure this was a good idea, since it leads people to come up with exotic theories.

在高版本的jdk中ConncurrentHashMap