expectedModCount和modCount关系，以及concurrentHashMap不加读锁的原因

public class TestArrayListIterator {
    public static void main(String[] args)  {
        ArrayList list = new ArrayList();
        list.add(10);
        Iterator iterator = list.iterator();
        while(iterator.hasNext()){
            Integer integer = iterator.next();
            if(integer==10)
                list.remove(integer);   //注意这个地方
        }
    }
}

题主可以调试下上面的这个程序，会报运行时异常 ConcurrentModificationException

Exception in thread "main" java.util.ConcurrentModificationException
	at java.util.AbstractList$Itr.checkForComodification(Unknown Source)
	at java.util.AbstractList$Itr.next(Unknown Source)
	at  com.notify.TestArrayListIterator.main(TestArrayListIterator.java:17)

在使用迭代器遍历的时候，如果使用ArrayList中的remove(int index) remove(Object o) remove(int fromIndex ,int toIndex) add等方法的时候都会修改modCount，在迭代的时候需要保持单线程的唯一操作，如果期间进行了插入或者删除，就会被迭代器检查获知，从而出现运行时异常

事实上在我们remove掉这个元素之后 ，该ArrayList的size()的值就变为了0，而此时Iterator的游标cursor是 1 ，在ArrayList迭代器的hasNext()方法中

public boolean hasNext() {
            return cursor != size();
	}

当中判断出cursor 确实不等于 size() 哭cry！！！！
然后循环又继续跑了！！！
如果我们不进行modCount和expectedModCount(创建迭代器的时候将当时的modCount赋值给expectedModCount)，这个程序肯定会报ArrayIndexOutOfBoundsException，这样的异常显然不是应该出现的(这些运行时错误都是使用者的逻辑错误导致的，我们的JDK那么高端，不会出现使用错误，我们只抛出使用者造成的错误，而这个错误是设计者应该考虑的)，为了避免出现这样的异常，定义了检查。

又想，为什么不把hasNext()的判断改为cursor <=size()呢？但是我们还有可能 add（）这样的话就会导致数据混乱，事实上线程安全本身就不允许读的时候被修改

==================================

ConcurrentHashMap完全允许多个读操作并发进行，读操作并不需要加锁。（事实上，ConcurrentHashMap支持完全并发的读以及一定程度并发的写。）如果使用传统的技术，如HashMap中的实现，如果允许可以在hash链的中间添加或删除元素，读操作不加锁将得到不一致的数据。但是ConcurrentHashMap实现技术是保证HashEntry几乎是不可变的。HashEntry代表每个hash链中的一个节点，其结构如下所示： 

 static final class HashEntry {
         final K key;
         final int hash;
         volatile V value;
         final HashEntry next;

         HashEntry(K key, int hash, HashEntry next, V value) {
             this.key = key;
             this.hash = hash;
             this.next = next;
             this.value = value;
         }

     @SuppressWarnings("unchecked")
     static final  HashEntry[] newArray(int i) {
         return new HashEntry[i];
     }
     }

可以看到除了value不是final的，其它值都是final的，这意味着 不能从hash链的中间或尾部添加或删除节点 ，因为这需要修改next引用值，所有的节点的修改只能从头部开始。对于put操作，可以一律添加到Hash链的头部。但是对于remove操作，可能需要从中间删除一个节点，这就需要将要删除节点的前面所有节点整个复制一遍，最后一个节点指向要删除结点的下一个结点。为了确保读操作能够看到最新的值，将value设置成volatile，这避免了加锁。 remove操作要注意一个问题：如果某个读操作在删除时已经定位到了旧的链表上，那么此操作仍然将能读到数据，只不过读取到的是旧数据而已，这在多线程里面是没有问题的。
HashEntry 类的 value 域被声明为 Volatile 型 ，Java 的内存模型可以保证：某个写线程对 value 域的写入马上可以被后续的某个读线程“看”到。在 ConcurrentHashMap 中，不允许用 null作为键和值，当读线程读到某个 HashEntry 的 value 域的值为 null 时，便知道产生了冲突——发生了重排序现象，需要加锁后重新读入这个 value 值。这些特性互相配合，使得读线程即使在不加锁状态下，也能正确访问 ConcurrentHashMap。 

在看源码实现时，对HashEntry 的 value 域的值可能为 null有些疑惑，网上都是说发生了重排序现象，后来仔细想想不完全正确，重排序发生在删除操作时，这只是其中的一个原因，尽管ConcurrentHashMap不允许将value为null的值加入，但现在仍然能够读到一个为空的value就意味着此值对当前线程还不可见，主要因为HashEntry还没有完全构造完成导致的，所以对添加和删除（对链表的结构性修改都可能会导致value为null）。