简单解析 兼顾高效与安全的ConcyrrentHashmap

本文深入探讨了ConcurrentHashMap在JDK1.7和JDK1.8中的实现原理,揭示了其如何通过细分锁粒度,从Segment+哈希表到哈希表+红黑树的转变,实现高并发场景下的线程安全与高性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我们直到?HashTable虽是线程安全的但是它锁住了整张hash表,所以性能很低,读读都互斥。那么ConcyrrentHashmap时如何在兼顾安全性的同时有实现高效性的呢?

  1. 首先是JDK1.7中ConcyrrentHashmap的实现原理

相对于线程安全的Hashtable来说,ConcyrrentHashmap的性能更高,原因是什么呢?在JDK1.7中ConcyrrentHashmap的底层实现是Segement+哈希表。如何理解呢?见下图:

在这里插入图片描述
在初始化后变为16个Segement且无法更改,不可扩容(是Segement不可扩容,初始化后就会定死为16)扩容的是Segement对应的小哈希表。
ConcyrrentHashmap锁的是这16个Segement,它由hashtable的一把锁变为Segement的16把锁,锁的粒度更细,支持的并发数增加。线程1拿到的Segement1的锁不会影响线程2访问其他的Segement。
Segement是ReentrantLock的子类,使用Lock来保证线程安全

2.JDK1.8中ConcyrrentHashmap实现原理

在JDK1.8中ConcyrrentHashmap的底层由原来的**”Segement+哈希表“**变为
“哈希表+红黑树”,不多说,直接上图:
在这里插入图片描述
此时的Segment值保留结构,支持扩容,且此时的ConcyrrentHashmap锁的是哈希桶(哈希表中的具体的每个头结点)粒度更细了锁的个数会随着表的扩容而增加

在这里插入图片描述
后续会具体说明关于多线程以及线程安全的问题

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值