ConcurrentHashMap底层原理

在上一篇博客中分析了HashMap是线程不安全的,那么要想使线程安全的一个办法就是加锁,也就是HashTable,在HashTable中的put(),get()方法都加上了synchronized关键字:

但HashTable是对整个HashMap加了锁,作用范围太大,导致性能下降,所以考虑给其中的一部分加锁。也就是对元素进行分组,然后给每一组分别加锁,这样就可以让多个元素共用一把锁(即分段锁:segment),元素在put的时候只需要看它是否能获取当前分组的锁即可,不会受到其他组的操作而受影响。每一个segment可以理解为是一个HashMap。即先有一个segment数组,每个segment数组中又存了一个数组是保存HashEntry的。

ConcurrentHashMap中的构造函数:

参数一默认值是16,指的是真正存数据的存储容量,也就是segment下存储的数组的容量。

参数二为加载因子,是真正存元素的数组的加载因子。

参数三是并发等级。

在上述的this()方法中初始化segment数组:

初始化每个segment下面存储的数组的大小:

结构图:

在执行put方法时:

最后调用put()放入HashEntry中:

使用完之后解锁:

以上就是java7中的concurrentHashMap的底层分析。

在java8中继续优化:

每次在put()的时候其实我们都是要去修改HashEntry数组中存的那个元素,即链表头部元素。所以我们可以只对数组中存的那个元素加锁即可。所以,在java8中不存在segment的概念。

Java8中的ConcurrentHashMap的底层结构:数组+链表+红黑树。

线程安全,key/value不为空。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

QYHuiiQ

听说打赏的人工资翻倍~

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值