转载 ConcurrentHashMap

最新推荐文章于 2023-03-21 22:26:35 发布

小Julie

最新推荐文章于 2023-03-21 22:26:35 发布

阅读量186

点赞数

https://blog.csdn.net/qq_24451605/article/details/51125946

点击打开链接

Java并发容器(一) CocurrentHashMap的应用及实现

原创 2016年04月11日 21:37:54

CocurrentHashMap的优势

为什么要使用ConcurrentHashMap

线程不安全的HashMap
HashMap是Java中最常用的一个Map类，00000性能好、速度快，但不能保证线程安全，它可用null作为key/value
在多线程环境下,使用HashMap进行put操作会引起死循环,所以在并发情况下不能使用HashMap.例如,执行以下代码会引起死循环.
线程安全的Map类，其public方法均用synchronize修饰
这表示在多线程操作时，每个线程在操作之前都会锁住整个map，待操作完成后才释放
如线程1使用put进行元素添加,线程2不但不能使用put方法进行添加元素,也不能使用get方法来获取元素,所以竞争越激烈效率越低,这必然导致多线程时性能不佳.另外，Hashtable不能使用null作为key/value

在多线程并发访问一个共享变量时，为了保证逻辑的正确，可以采用以下方法：

加锁，性能最低，能保证原子性、可见性，防止指令重排；
volatile修饰，性能中等，能保证可见性，防止指令重排；
使用getObjectVolatile，性能最好，可防止指令重排；
因此ConcurrentHashMap选择了使用Unsafe的getObjectVolatile来读取segments中的元素，

首先常用三种HashMap包括HashMap,HashTable和CocurrentHashMap：

HashMap在并发编程过程中使用可能导致死循环，因为插入过程不是原子操作，每个HashEntry是一个链表节点，很可能在插入的过程中，已经设置了后节点，实际还未插入，最终反而插入在后节点之后，造成链中出现环，破坏了链表的性质，失去了尾节点，出现死循环。
HashTable因为内部是采用synchronized来保证线程安全的，但在线程竞争激烈的情况下HashTable的效率下降得很快因为synchronized关键字会造成代码块或方法成为为临界区(对同一个对象加互斥锁)，当一个线程访问临界区的代码时，其他线程也访问同一临界区时，会进入阻塞或轮询状态。究其原因，实际上是有获取锁意向的线程的数目增加，但是锁还是只有单个，导致大量的线程处于轮询或阻塞，导致同一时间段有效执行的线程的增量远不及线程总体增量。
在查询时，尤其能够体现出CocurrentHashMap在效率上的优势，HashTable使用Sychronized关键字，会导致同时只能有一个查询在执行，而Cocurrent则不采取加锁的方法，而是采用volatile关键字，虽然也会牺牲效率，但是由于Sychronized，于该文末尾继续讨论。
CocurrentHashMap利用锁分段技术增加了锁的数目，从而使争夺同一把锁的线程的数目得到控制。
- 锁分段技术就是对数据集进行分段，每段竞争一把锁，不同数据段的数据不存在锁竞争，从而有效提高高并发访问效率。
- CocurrentHashMap在get方法是无需加锁的，因为用到的共享变量都采用volatile关键字修饰，共享变量在线程之间的可见性(每次读取都先同步缓存和内存，直接从内存中获取值，虽然不是原子操作，但根据JAVA内存模型的happen before原则，对volatile字段的写入操作先于读操作，能够保证不会脏读),volatile为了让变量提供线程之间的内存可见性，会禁止程序执行结果的重排序（导致缓存优化的效果降低）

CocurrentHashMap的结构

CocurrentHashMap是由Segment数组和HashEntry数组组成。
Segment是重入锁(ReentrantLock),作为一个数据段竞争锁，每个HashEntry一个链表结构的元素，利用Hash算法得到索引确定归属的数据段，也就是对应到在修改时需要竞争获取的锁。

segments数组的初始化

if ( cocurrencyLevel > MAX_SEGMENTS )
    cocurrencyLevel = MAX_SEGMENTS;
//如果cocurrencyLevel大于上限，那么取值为上限，
//上限定义为65535，决定了重入锁的segments的数目
int sshift = 0;
int ssize = 1;
//找到大于等于concurrencyLevel的最小的2^n作为segments的大小
while ( ssize < concurrencyLevel ){
    ++sshift;//记录偏移量，为了以后通过与运算获取segment的索引
    ssize <<=1;
}
segmentShift = 32 - sshift;//说明只有高sshift位作为segment的索引
segmentMask = ssize - 1;//能直接通过与运算获取segment的索引
this.segments = Segment.newArray(ssize);
//静态工厂方法构造ssize大小的segment数组

初始化每个segment,因为已经知道segment数组的规模，将ConcurrentHashMap的逻辑上持有的HashEntry均分到每个Segment上，因为是散列，所以要loadFactor来定义负载率，来保证segment适时的拓充，来避免散列表和数据规模相近时，冲突加重的风险。
定位segment，定位segment尤其重要，如果太多元素集中在少数几个segment中会导致CocurrentHashMap的效率得不到优化，因为同一个segment中的修改还是要竞争锁，所以选择合适的hash算法尽可能地将元素分到不同的segment中是目标。
- CocurrentHashMap采用的是对元素的HashCode进行再Hash来减少冲突
- CocurrentHashMap采用的是根据Wang/JenkinsHash改进的hash算法，该算法具有雪崩性(参数一位数字变化，结果都有半数左右(二进制位)发生变化)

final Segment<K,V> segmentFor ( int hash ){ //首先根据segmentShift无符号右移，得到表示segment所以的高位， //然后与掩码逻辑与得到segment的索引，定位到segment return segments[(hash>>>segmentShift)&segmentMask]; }

CocurrentHashMap的操作

Segment的get操作是不需要加锁的。因为get() 将使用的共享变量全部定义为volatile类型。修饰的变量保证了线程之间的可见性
Segment的put操作是需要加锁的，在插入时会先判断Segment里的HashEntry数组是否会超过容量(threshold),如果超过需要对数组扩容，翻一倍。然后在新的数组中重新hash，为了高效，CocurrentHashMap只会对需要扩容的单个Segment进行扩容
put、remove、replace、clear方法要使用锁，但并不一定有锁争用，原因在于ConcurrentHashMap将缓存的变量分到多个Segment，每个Segment上有一个锁，只要多个线程访问的不是一个Segment就没有锁争用，就没有堵塞，各线程用各自的锁，ConcurrentHashMap缺省情况下生成16个Segment，也就是允许16个线程并发的更新而尽量没有锁争用；
Iterator对象的使用，不一定是和其它更新线程同步，获得的对象可能是更新前的对象，ConcurrentHashMap允许一边更新、一边遍历，也就是说在Iterator对象遍历的时候，ConcurrentHashMap也可以进行remove,put操作，且遍历的数据会随着remove,put操作产出变化。所以希望遍历到当前全部数据的话，要么以ConcurrentHashMap变量为锁进行同步(synchronized该变量)【效率低】，要么使用CopiedIterator包装iterator，使其拷贝当前集合的全部数据，但是这样生成的iterator不可以进行remove操作。
Size 操作：Segment里的全局变量count是一个volatile,在并发场景下,是不是直接把所有Segment的count相加就可以得到整个ConcurrentHashMap大小了呢?不是的。CocurrentHashMap获取size的时候要统计Segments中的HashEntry的和，如果不对他们都加锁的话，无法避免数据的修改造成的错误，但是如果都加锁的话，效率又很低。所以CoccurentHashMap在实现的时候，巧妙地利用了在累加过程中发生变化的几率很小的客观条件，在获取count时，不加锁的计算两次，如果两次不相同，在采用加锁的计算方法。采用了一个高效率的剪枝防止很大概率地减少了不必要额加锁。

那么ConcurrentHashMap又是如何判断在统计的时候容器是否发生了变化呢? 使用modCount变量,在put、remove和clean方法里操作元素前都会将变量modCount进行加1,那么在统计size前后比较modCount是否发生变化,从而得知容器的大小是否发生变化.

一点理解

synchronized(其实感觉是可以被重入锁和Condition完全取代的)和volatile的取舍：

首先的区别就在于是否是原子操作，也就是单一的不可分割的操作，在多线程中，原子操作能够保证不受到其他线程的影响
synchonized就实现了原子性操作，不同的线程互斥地进入临界代码区，而且是内存可见的，也就是每个线程进入临界区时，都是从内存中获取的值，不会因为缓存而出现脏读。
volatile实现了内存可见性，会将修改的值直接写入内容，并且注销掉之前对于该变量的缓存，而且禁止了指令的排序。但是它不是原子操作！！