ConcurrentHashMap1.7和1.8设计思想

1.7中的ConcurrentHashMap的介绍

HashMap是一个线程不安全的集合&＃xff0c;如果想要在并发下让他线程安全那么可以使用Hashtable&＃xff0c;但是Hashtable是对整个集合进行加锁&＃xff0c;这明显也不是我们想要的。按照历史经验来讲&＃xff0c;要提升性能比较好想到的手段就是减小锁的粒度。

在ConcurrentHashMap1.7中使用了一组Segment集合作为作为锁&＃xff0c;它的底层继承自ReentrantLock&＃xff0c;Segment里面包含了一个HashEntry数组&＃xff0c;HashEntry是一个链表结构的元素&＃xff0c;每一个Segment分别锁定整个集合中的一部分数据&＃xff0c;从而实现减小锁粒度提升并发能力的目的。

当发生并发更新的时候&＃xff0c;首先求出key的hash值并定位到具体的segment&＃xff0c;检查当前segment是否初始化&＃xff0c;因为ConcurrentHashMap初始化时只会初始化第一个segment&＃xff1b;之后对当前的segment尝试加锁&＃xff0c;如果加锁失败将采用CAS进行自旋等待获取锁。

1.7中的ConcurrentHashMap是写锁而不是读写锁&＃xff0c;所以在读数据的时候并没加锁&＃xff0c;而是使用了volatile关键字修饰value&＃xff0c;使其读的时候可以立马获取其他线程修改后的值。

在使用ConcurrentHashMap的时候&＃xff0c;应该尽量避免使用size、containsValue因为最坏条件下ConcurrentHashMap可能会升级为全局锁。

1.8中的ConcurrentHashMap的介绍

1.7中的ConcurrentHashMap使用了分段锁的思想&＃xff0c;要想实现更好的并发性就是继续减小索粒度。在1.8中的ConcurrentHashMap采用table数组元素作为锁&＃xff0c;从而实现了更小的索粒度&＃xff0c;进一步减少并发冲突概率。

这就让我感觉很多技术思想都是相通的&＃xff0c;Hashtable&＃xff0c;ConcurrentHashMap1.7到1.8很容易类比到MySQL的表锁&＃xff0c;分段锁和行锁。都是尽可能的减小锁粒度从而提交并发性能。

1.7中的ConcurrentHashMap采用数组&＃43;单链表的数据结构对于一个hash表来说&＃xff0c;最核心的能力就是将key hash之后能够均匀的分布&＃xff0c;那么table数组中的每个队列长度主要为0或者1。但实际情况也并非如此理想&＃xff0c;虽然ConcurrentHashMap类默认的加载因子是0.75&＃xff0c;但是在数据量过大或者运气不佳的情况下&＃xff0c;还是会存在一些队列长度过长的情况&＃xff0c;如果还是采用单链表方式&＃xff0c;那么某个节点的查询的时间复杂度就会退化成为O&＃xff08;n&＃xff09;;因此对于超过8的列表&＃xff0c;jdk1.8中采用了红黑树的结构&＃xff0c;那么时间复杂度就可以降低到O&＃xff08;logN&＃xff09;;