ConcurrentHashMap的锁分段技术：可以看做多个hashtable组成一个ConcurrentHashMap，分段加锁。当要修改ConcurrentHashMap结构时，要按顺序加锁每个hashtable，都是fianl类型(数组，元素都是final)，保证顺序性，这样不会发生死锁。
ConcurrentHashMap的读 不要加锁。get操作不需要锁。第一步是访问count变量，这是一个volatile变量，由于所有的修改操作在进行结构修改时都会在最后一步写count 变量， 通过这种机制保证get操作能够得到几乎最新的结构更新。对于非结构更新，也就是结点值的改变，由于HashEntry的value变量是 volatile的，也能保证读取到最新的值。接下来 就是根据hash和key对hash链进行遍历找到要获取的结点，如果没有找到，直接访回null。对hash链进行遍历不需要加锁的原因在于链指针next是final的。但是头指针却不是 final的，这是通过getFirst(hash)方法返回，也就是存在 table数组中的值。这使得getFirst(hash)可能返回过时的头结点，例如，当执行get方法时，刚执行完getFirst(hash) 之后，另一个线程执行了删除操作并更新头结点，这就导致get方法中返回的头结点不是最新的。这是可以允许，通过对count变量的协调机制，get能读取到几乎最新的数据，虽 然可能不是最新的。要得到最新的数据，只有采用完全的同步。
ConcurrentHashMap的迭代器是弱一致性的迭代器。它的get，clear方法和迭代器都是“弱一致性”的。get方法是弱一致的，是什么含义？可能你期望往ConcurrentHashMap底层 数据结构中加入一个元素后，立马能对get可见，但ConcurrentHashMap并不能如你所愿。换句话说，put操作将一个元素加入到底层数据结构后，get可能在某段时间内还看不到 这个元素，若不考虑内存模型，单从代码逻辑上来看，却是应该可以看得到的。
弱一致性:
引用:http://ifeve.com/concurrenthashmap-weakly-consistent/