通过分析Hashtable就知道，synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术。它使用了多个锁来控制对hash表的不同部分进行的修改。ConcurrentHashMap内部使用段(Segment)来表示这些不同的部分，每个段其实就是一个小的hash table，它们有自己的锁。只要多个修改操作发生在不同的段上，它们就可以并发进行。
有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁。这里“按顺序”是很重要的，否则极有可能出现死锁，在ConcurrentHashMap内部，段数组是final的，并且其成员变量实际上也是final的，但是，仅仅是将数组声明为final的并不保证数组成员也是final的，这需要实现上的保证。这可以确保不会出现死锁，因为获得锁的顺序是固定的。一、结构解析
对比上图，HashTable实现锁的方式是锁整个hash表，而ConcurrentHashMap的实现方式是锁桶（简单理解就是将整个hash表想象成一大缸水，现在将这大缸里的水分到了几个水桶里，hashTable每次都锁定这个大缸，而ConcurrentHashMap则每次只锁定其中一个 桶）。
ConcurrentHashMap将hash表分为16个桶（默认值），诸如get,put,remove等常用操作只锁当前需要用到的桶。试想，原来 只能一个线程进入，现在却能同时16个写线程进入，并发性的提升是显而易见的。
ConcurrentHashMap和Hashtable主要区别就是围绕着锁的粒度以及如何锁,可以简单理解成把一个大的HashTable分解成多个，形成了锁分离。
而Hashtable的实现方式是---锁整个hash表
ConCurrentHashMap remove()方法
当对ConcurrentHashMap进行remove操作时，并不是进行简单的节点删除操作，对比上图，当对ConcurrentHashMap的一个segment也就是一个桶中的节点进行remove后，例如删除节点C，C节点实际并没有被销毁，而是将C节点前面的反转并拷贝到新的链表中，C节点后面的不需要被克隆。这样来保持并发的读线程不受并发的写线程的干扰。例如现在有一个读线程读到了A节点，写线程把C删掉了，但是看上图，读线程仍然可以继续读下去；当然，如果在删除C之前读线程读到的是D，那么更不会有影响。ConcurrentHashMap中删除一个节点并不会立刻被读线程感受到的效果，就是传说中的弱一致性，所以ConcurrentHashMap的迭代器是弱一致性迭代器。下面是删除的图：
那为什么是倒序的呢？
是因为hashentry 结构的额不可变性，即第一次设置next属性之后就不在改变，所以是需要克隆下来的，但是你要删除C点你肯定是从C忘头结点走、
ConcurrentHashMap完全允许多个读操作并发进行，读操作并不需要加锁。如果使用传统的技术，如HashMap中的实现，如果允许可以在hash链的中间添加或删除元素，读操作不加锁将得到不一致的数据。ConcurrentHashMap实现技术是保证HashEntry几乎是不可变的。
HashEntry代表每个hash链中的一个节点，其结构如下所示：
static final class HashEntry<K,V> {
final K key;
final int hash;
volatile V value;
final HashEntry<K,V> next;
}
可以看到除了value不是final的，其它值都是final的，这意味着不能从hash链的中间或尾部添加或删除节点，因为这需要修改next 引用值，所有的节点的修改只能从头部开始。对于put操作，可以一律添加到Hash链的头部。但是对于remove操作，可能需要从中间删除一个节点，这就需要将要删除节点的前面所有节点整个复制一遍，最后一个节点指向要删除结点的下一个结点。
