ConcurrentHashMap

ConcurrentHashMap  

主要两个结构：Segment[]  和 HashEntry[]

每个Segment是一个ReentrantLock

Segment结构跟HashMap差不多，成员：table，count，loadFactor，threshold，modCount

每个Segment继承ReentrantLock，实现Serializable

定义了一般的map方法，get，put，clear，containsKey，containsValue，replace，rehash

table里面是HashEntry，成员key，value，next，hash

 

找Segment的index，hash(object.hashCode())，index = (hash>>>sigmentShift(28))&segmentMask(16)

找HashEntry的index，index = (hash & tab.length-1)

总结：找Segment利用的是hash值的高四位，找Entry利用的是hash值的低四位，所以还有中间24位都没有用到

 

get  不加锁，只有在发现当hash值和key等相等，但value是null，才会加锁(readValueUnderLock)，保证value的读取。

因为new出来的Entry是赋值给table里面的，虽然table是volatile，但里面的元素的赋值不是，所以就有可能出现引用和初始化被重排序，导致读到的value是null的现象，所以只能加锁避免。(跟是不是new JMM没关系)

 

put 整个过程加锁。遍历entry链，如果key存在相同，覆盖旧的value(hashEntry类里只有value不是final的)

如果不存在，new HashEntry，将first设置为它的next，将新entry设置到数组table相应的位置

 

rehash

小优化：预先遍历一个bucket里面的entry，找到最末尾连续的一段新索引(lastIdx)都相同的链表，将它们直接设置到新的数组位置

这里不用担心"直接"赋值会不会覆盖数据，因为每次都是扩充2倍，算法上是不会出现这种情况

剩余的entry就需要一个一个创建新entry放到各自不同的数组位置

 

remove

保留要删除的entry后面的链表，将该entry之前的节点重新创建一遍，从first开始遍历，导致前面一段的顺序反转了

 

 

 

JDK7对ConcurrentHashMap进行改进

 

get  抛弃掉判断null再加锁方式，而是用unsafe工具的getObjectVolatile方式来读数组里的元素

 

put  先去tryLock(自旋)，如果不能获得锁，执行

scanAndLockForPut

加入了自旋(tryLock)的机制，自旋一定次数(MAX_SCAN_RETRIES 默认64)后执行lock。

自旋过程中会检查entry链的first是否有变化，如果有变化，重新从新的first开始遍历，retires设置为-1

返回HashEntry，在获取锁之前，可以先找到要替换或者是创建要插入的新entry

 

remove

不再重新创建要删除节点之前的链表，而是直接做最简单的pred.next=next。利用了系统底层级别的缓存特性。保证了读线程的并发正确性

所以entry中的next从final变成了volatile