public V get(Object key) {
int hash = hash(key); // throws NullPointerException if key null
return segmentFor(hash).get(key, hash);
}V get(Object key, int hash) {
if(count != 0) { // 首先读 count 变量
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;
// 如果读到 value 域为 null，说明发生了重排序，加锁后重新读取
return readValueUnderLock(e);
}
e = e.next;
}
}
return null;
}ConcurrentHashMap完全允许多个读操作并发进行，读操作并不需要加锁。关键是用 HashEntry 对象的不变性来降低读操作对加锁的需求。只是判断获取的entry的value是否为null，为null时才使用加锁的方式再次去获取。 在代码清单“HashEntry 类的定义”中我们可以看到，HashEntry 中的 key，hash，next 都声明为 final 型。这意味着，不能把节点添加到链接的中间和尾部，也不能在链接的中间和尾部删除节点。这个特性可以保证：在访问某个节点时，这个节点之后的链接不会被改变。这个特性可以大大降低处理链表时的复杂性。 下面分析在get的时候的线程安全性
get的过程中另一个线程恰好新增entry
HashEntry 类的 value 域被声明为 volatile 型，Java 的内存模型可以保证：某个写线程对 value 域的写入马上可以被后续的某个读线程“看”到。在 ConcurrentHashMap 中，不允许用 null 作为键和值，当读线程读到某个 HashEntry 的 value 域的值为 null 时，便知道发生了指令重排序现象(注意：volatile变量重排序规则，同时也是先行发生原则的一部分：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后顺序。所以，在tab[index] = new HashEntry<K,V>(key, hash, first, value);中，可能会出现当前线程得到的newEntry对象是一个没有完全构造好的对象引用。)，需要加锁后重新读入这个 value 值。
如果get的过程中另一个线程修改了一个entry的value
由于对 volatile 变量的可见性，写线程对链表的非结构性修改能够被后续不加锁的读线程“看到”。
