有关ConcurrentHashMap原理总结

最新推荐文章于 2024-03-22 09:49:18 发布

亮亮在江湖

最新推荐文章于 2024-03-22 09:49:18 发布

阅读量323

点赞数

分类专栏：面试题进阶类

本文链接：https://blog.csdn.net/lou_liang/article/details/106306837

版权

进阶类同时被 2 个专栏收录

37 篇文章 2 订阅

订阅专栏

面试题

4 篇文章 1 订阅

订阅专栏

jdk1.7 时性能分析
如图所示，是由 Segment 数组、HashEntry 组成，和 HashMap 一样，仍然是数组加链表

Segment 是 ConcurrentHashMap 的一个内部类，主要的组成如下：

static final class Segment<K,V> extends ReentrantLock implements Serializable {  
  
    private static final long serialVersionUID = 2249069246763182397L;    

    // 和 HashMap 中的 HashEntry 作用一样，真正存放数据的桶   
     transient volatile HashEntry<K,V>[] table;    
     transient int count;        
     transient int modCount;        
     transient int threshold;        
    final float loadFactor;
}

HashEntry跟HashMap差不多的，但是不同点是，他使用volatile去修饰了他的数据Value还有下一个节点next

volatile的特性：
（1）保证了不同线程对变量进行操作时的可见性，即一个线程修改了某个变量的值，对其他线程来说是立即可见的。（可见性）（2）、禁止进行指令重排序。（有序性）
（3）、volatile 只能保证对单次读/写的原子性。i++ 这种操作不能保证原子性

并发性高的原因：

ConcurrentHashMap 采用了分段锁技术，其中 Segment 继承于 ReentrantLock。不会像 HashTable 那样不管是 put 还是 get 操作都需要做同步处理，理论上 ConcurrentHashMap 支持 CurrencyLevel 线程并发。

每当一个线程占用锁访问一个 Segment 时，不会影响到其他的 Segment。就是说如果容量大小是16他的并发度就是16，可以同时允许16个线程操作16个Segment而且还是线程安全的。

举个栗子：分段锁，只锁部分，用到哪部分就锁哪部分。一个大仓库，里面有若干个隔间，每个隔间都有锁，同时只允许一个人进隔间存取东西。但是，在存取东西之前，需要有一个全局索引，告诉你要操作的资源在哪个隔间里，然后当你看到隔间空闲时，就可以进去存取，如果隔间正在占用，那你就得等着。

看一下put源代码，你就知道他是怎么做到线程安全：

首先第一步的时候会尝试获取锁，如果获取失败肯定就有其他线程存在竞争，则利用 scanAndLockForPut() 自旋获取锁。

尝试自旋获取锁。
如果重试的次数达到了 MAX_SCAN_RETRIES 则改为阻塞锁获取，保证能获取成功。

ConcurrentHashMap的get 逻辑比较简单：
只需要将 Key 通过 Hash 之后定位到具体的 Segment ，再通过一次 Hash 定位到具体的元素上。由于 HashEntry 中的 value 属性是用 volatile 关键词修饰的，保证了内存可见性，所以每次获取时都是最新值，整个过程都不需要加锁。
但是效率依然低：
存在问题是数组加链表的方式，我们去查询的时候，还得遍历链表，会导致效率很低，在jdk1.8完全优化了。

jdk1.8性能分析：
跟HashMap很像，也把之前的HashEntry改成了Node，但是作用不变，把值和next采用了volatile去修饰，保证了可见性，并且也引入了红黑树，在链表大于一定值的时候会转换（默认是8）

ConcurrentHashMap在进行put操作的还是比较复杂的，大致可以分为以下步骤：

根据 key 计算出 hashcode 。
判断是否需要进行初始化。
即为当前 key 定位出的 Node，如果为空表示当前位置可以写入数据，利用 CAS 尝试写入，失败则自旋保证成功。
如果当前位置的 hashcode == MOVED == -1,则需要进行扩容。
如果都不满足，则利用 synchronized 锁写入数据。
如果数量大于 TREEIFY_THRESHOLD 则要转换为红黑树。

ConcurrentHashMap的get操作

根据计算出来的 hashcode 寻址，如果就在桶上那么直接返回值。
如果是红黑树那就按照树的方式获取值。
就不满足那就按照链表的方式遍历获取值

总结：
从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树

1、JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，JDK1.8的实现降低锁的粒度，就是HashEntry（首节点）

2、JDK1.8版本的数据结构变得更加简单，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了

3、JDK1.8使用红黑树来优化链表遍历效率是很快的，JDK1.7基于链表的遍历是一个很漫长的过程，而代替一定阈值的链表

JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock，我觉得有以下几点：

（1）、因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差，在粗粒度加锁中ReentrantLock可能通过Condition来控制各个低粒度的边界，更加的灵活，而在低粒度中，Condition的优势就没有了
（2）、JVM的开发团队从来都没有放弃synchronized，而且基于JVM的synchronized优化空间更大
（3）、在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更多的内存