ConcurrentHashMap(JDK1.8)为什么要放弃Segment

最新推荐文章于 2024-10-10 15:51:08 发布
最新推荐文章于 2024-10-10 15:51:08 发布
阅读量2.1w 收藏 23
点赞数 12
分类专栏： 源码分析 经验总结 文章标签： jdk 面试 hashmap 并发
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/mian_csdn/article/details/70185104
版权

今天看到一篇博客：jdk1.8的HashMap和ConcurrentHashMap，我想起了前段时间面试的一个问题：ConcurrentHashMap(JDK1.8)为什么要使用synchronized而不是如ReentranLock这样的可重入锁？

我想从下面几个角度讨论这个问题：

  1. 锁的粒度
    首先锁的粒度并没有变粗，甚至变得更细了。每当扩容一次，ConcurrentHashMap的并发度就扩大一倍。
  2. Hash冲突
    JDK1.7中，ConcurrentHashMap从过二次hash的方式（Segment -> HashEntry）能够快速的找到查找的元素。在1.8中通过链表加红黑树的形式弥补了put、get时的性能差距。
  3. 扩容
    JDK1.8中，在ConcurrentHashmap进行扩容时，其他线程可以通过检测数组中的节点决定是否对这条链表（红黑树）进行扩容，减小了扩容的粒度，提高了扩容的效率。

下面是我对面试中的那个问题的一下看法：

为什么是synchronized，而不是可重入锁
1. 减少内存开销
假设使用可重入锁来获得同步支持，那么每个节点都需要通过继承AQS来获得同步支持。但并不是每个节点都需要获得同步支持的，只有链表的头节点（红黑树的根节点）需要同步，这无疑带来了巨大内存浪费。
2. 获得JVM的支持
可重入锁毕竟是API这个级别的，后续的性能优化空间很小。
synchronized则是JVM直接支持的，JVM能够在运行时作出相应的优化措施：锁粗化、锁消除、锁自旋等等。这就使得synchronized能够随着JDK版本的升级而不改动代码的前提下获得性能上的提升。

我不能保证写的东西完全正确
但是我能保证我写的东西都是经过思考之后所得出，而不是复制粘贴得来
如果有不对的地方，希望您能够指正，谢谢～

那只是一股逆流
关注
专栏目录
多线程 - java8的ConcurrentHashMap为何放弃分段锁，为什么要使用CAS+Synchronized取代Segment+ReentrantLock
学无止境
02-22 1848
【java8的ConcurrentHashMap为何放弃分段锁，为什么要使用CAS+Synchronized取代Segment+ReentrantLock】
【java】并发容器之ConcurrentHashMap(JDK 1.8版本)
九师兄
06-03 3840
在使用HashMap时在多线程情况下扩容会出现CPU接近100%的情况，因为hashmap并不是线程安全的，通常我们可以使用在java体系中古老的hashtable类，该类基本上所有的方法都采用synchronized进行线程安全的控制，可想而知，在高并发的情况下，每次只有一个线程能够获取对象监视器锁，这样的并发性能的确不令人满意。另外一种方式通过Collections的将hashmap包装成一个线程安全的map。
java8的ConcurrentHashMap为何放弃分段锁
MARKPAIN的专栏
07-09 1万+
现在看不懂系列，呜呜呜。 https://my.oschina.net/pingpangkuangmo/blog/817973 https://www.wanaright.com/2018/09/30/java10-concurrenthashmap-no-segment-lock/ https://blog.csdn.net/mian_csdn/article/details/70185104 ...
JDK1.8 论ConcurrentHashMap是如何扩容的
最新发布
2401_87878486的博客
10-10 580
看上面的注释1,每次都会对 baseCount 加1,如果并发竞争太大，可能导致 U.compareAndSwapLong(this,BASECOUNT,b=baseCount,s = b + x) 失败,为了提高高并发的时候 baseCount 可见性的失败的问题,又避免一直重试，这样性能会有很大的影响,直接用fullAddCount函数完成整个过程。tableSizeFor(n):n向上取整2的整数次方，若n是5，本身不是2的整数次方，但是向上有最近的8是2的整数次方，返回8；
面试官：ConcurrentHashMap为什么放弃了分段锁？
磊哥聊Java
09-24 3845
今天我们来讨论一下一个比较经典的面试题就是 ConcurrentHashMap 为什么放弃使用了分段锁，这个面试题阿粉相信很多人肯定觉得有点头疼，因为很少有人在开发中去研究这块的内容，今天...
Java8开始ConcurrentHashMap,为什么舍弃分段锁?
qq_37437493的博客
07-19 487
分段锁，保证在操作不同段 map 的时候， 可以并发执行， 操作同段 map 的时候，进行锁的竞争和等待。JDK1.8中，在ConcurrentHashmap进行扩容时，其他线程可以通过检测数组中的节点决定是否对这条链表（红黑树）进行扩容，减小了扩容的粒度，提高了扩容的效率。然后， 如果不是链表第一个object， 则直接用链表第一个object加锁，这里加的锁是synchronized，虽然效率不如ReentrantLock， 但节约了空间，这里会一直用第一个object为锁， 直到重新计算map大小，
硬核讲解JDK1.8的ConcurrentHashMap为何放弃分段锁改用CAS + synchronized
热门推荐
李昊轩的博客
04-15 3万+
jdk1.7分段锁的实现 和hashmap一样，在jdk1.7中ConcurrentHashMap的底层数据结构是数组加链表。和hashmap不同的是ConcurrentHashMap中存放的数据是一段段的，即由多个Segment(段)组成的。每个Segment中都有着类似于数组加链表的结构。 关于Segment ConcurrentHashMap有3个参数： initialCapacity：初...
ConcurrentHashMap JDK1.8中结构原理及源码分析
工作记录
09-17 1435
注：本文根据网络和部分书籍整理基于JDK1.8书写，如有雷同敬请谅解  欢迎指正文中的错误之处。 数据结构       ConcurrentHashMap 1.8 抛弃了Segment分段锁机制，采用Node + CAS + Synchronized来保证并发安全进行实现，采用table数组＋链表＋红黑树的存储结构。以table数组元素作为锁，利用CAS+Synchronized来保证并发更新...
JDK1.8 ConcurrentHashMap
A_BCDEF_的博客
03-01 663
将table分成n份 ，每份长度为stride，table大小除以CPU数量，平分给各个线程，每个线程对当前旧table中[transferIndex-stride, transferIndex-1]位置的结点进行迁移。迁移时不需要rehash，同hashmap一样计算新下标即可。JDK1.8 中采用CAS + synchronized，锁首节点，粒度更小。hash定位到node，复制节点前的链与节点后的链相连，跳过节点，即为删除。∵使用volatile修饰next，所以next值具有不变性，需要头插。
java之ConcurrentHashMap在jdk1.7和jdk1.8中的不同
感冒石头的博客
12-14 1230
1.底层结构发生变化jdk 1.7底层结构是：数组（Segment）+ 链表（HashEntry节点）组成 使用分段锁技术，将整个数据结构分段（默认为16段）进行存储，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。如下图是ConcurrentHashMap的内部结构图： 从上面的结构我们可以了...
ConcurrentHashMap JDK1.8 源码
Top5软件工程硕士，先后在京东、字节从事多年Java后端开发、实时和离线大数据开发
04-16 303
put: 检查key或value是否为空，如果key或value为空，则抛异常，反之进入for死循环， 检查table是否初始化了，如果没有，则进行初始化（初始化完成后进行下一次循环），如果已经初始化则根据key找到hash表中索引位置table[i]， 如果没有发生碰撞，则利用CAS操作直接存储在table[i]，如果成功则退出循环，反之进行下一次循环 如...
Java8开始ConcurrentHashMap,为什么舍弃分段锁
天才小站
12-27 1万+
概述 我们知道， 在 Java 5 之后，JDK 引入了 java.util.concurrent 并发包 ，其中最常用的就是ConcurrentHashMap 了， 它的原理是引用了内部的 Segment (ReentrantLock ) 分段锁，保证在操作不同段 map 的时候， 可以并发执行， 操作同段 map 的时候，进行锁的竞争和等待。从而达到线程安全， 且效率大于 synchr...
面试官：为什么ConcurrentHashMap要放弃分段锁？
磊哥聊Java
08-09 321
今天我们来讨论一下一个比较经典的面试题就是 ConcurrentHashMap 为什么放弃使用了分段锁，这个面试题阿粉相信很多人肯定觉得有点头疼，因为很少有人在开发中去研究这块的内容，今天阿粉就来给大家讲一下这个 ConcurrentHashMap 为什么在 JDK8 中放弃了使用分段锁。什么是分段锁我们都知道 HashMap 是一个线程不安全的类，多线程环境下，使用 H...
问到ConcurrentHashMap不要再提Segment了
学习
01-09 1068
HashMap是面试中的高频问题，前面已经介绍了JDK7he JDK8下hashMap的区别。但他是线程不安全的， 而本文则重点介绍ConcurrentHashMap实现的细节 HashTable是一个线程安全的类，它使用synchronized来锁住整张Hash表来实现线程安全，即每次锁住整张表让线程独占。 JDK8的ConcurrentHashMap结构相比较JDK1.7发生了很大的变化。取消...
黑马-ConcurrentHashMap
qq_36811160的博客
01-14 1044
ConcurrentHashMap
理解 ConcurrentHashMap
qq_43325216的博客
05-05 1996
ConcurrentHashMap的实现原理 ConcurrentHashMap 在 JDK1.7 和 JDK1.8 的实现方式是不同的 JDK1.7下的ConcurrentHashMap 实现原理是数组加链表，jdk1.7下，ConcurrentHashMap由segment 数组结构和 hashEntry 数组结构构成的，每个hashEntry相当于HashMap 中的table数组，即 ConcurrentHashMap 把哈希桶数组切分成小数组（Segment ），每个小数组有 n 个 Has
【Java并发】- ConcurrentHashMap原理解析(Segment版本)（转）
LightOfMiracle的博客
06-14 4288
ConcurrentHashMap原理解析原文链接：http://www.iteye.com/topic/1103980ConcurrentHashMap是一个线程安全的哈希表结构，它的主要功能是提供了一组和HashTable功能相同但是线程安全的方法。ConcurrentHashMap可以做到读取数据不加锁，并且其内部的结构可以让其在进行写操作的时候能够将锁的粒度保持地尽量地小，不用对整个Conc
concurrenthashmap jdk1.7与jdk1.8区别
04-05
1. Segment 数量 在 JDK1.7 中 ConcurrentHashMap 内部的 Segment 数组的长度是固定的，由一个常量指定，即 16。每个 Segment 可以被看作是一个小的 ConcurrentHashMap。在 JDK1.8 中，Segment 被取消了，取而代之的是一个名为 Node 的数组，这个数组的长度是可变的，它的长度被初始化为 2 的幂次方，具体的大小取决于当前 ConcurrentHashMap 中元素的数量。 2. 数据结构 在 JDK1.7 中 ConcurrentHashMap 内部的每个 Segment 由一个 HashEntry 数组和一个 HashEntry 链表组成。当多个线程同时访问 ConcurrentHashMap 时，它们只会锁定对应的 Segment，而不是整个 ConcurrentHashMap。在 JDK1.8 中，每个 Node 是一个单独的元素，它可以包含多个 key-value 对，每个 Node 之间通过链表进行关联。 3. 锁的优化 在 JDK1.8 中，ConcurrentHashMap 中使用了 CAS 操作来进行锁的优化。在 JDK1.7 中，ConcurrentHashMap 中需要使用锁来保证线程安全，这个锁是对每个 Segment 进行的，也就是说，在多线程访问 ConcurrentHashMap 时，每个线程只能同时访问不同的 Segment，这样可以避免锁的竞争，提高了并发性能。 4. 数据存储方式 在 JDK1.7 中 ConcurrentHashMap 中的数据存储方式是数组和链表结合的方式，其中数组是用来存储数据的，链表是用来解决哈希冲突的。而在 JDK1.8 中 ConcurrentHashMap 中的数据存储方式是数组和链表以及红黑树结合的方式，当链表长度大于 8 时，链表会自动转化为红黑树，这样可以提高查找效率。 5. 性能 由于 JDK1.8 中 ConcurrentHashMap 中使用了 CAS 操作来进行锁的优化，因此在并发性能方面有了很大的提升。同时，在数据存储方式方面，JDK1.8 中 ConcurrentHashMap 中使用了红黑树来优化哈希冲突，这样可以提高查找效率。因此，JDK1.8 中 ConcurrentHashMap 的性能比 JDK1.7 中 ConcurrentHashMap 更加出色。
评论 15
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值