get的过程中另一个线程恰好新增entry

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 变量的可见性，写线程对链表的非结构性修改能够被后续不加锁的读线程“看到”。