ConcurrentHashMap源码分析

ConcurrentHashMap是线程安全的HashMap的实现。

put(Object key, Object value):

  ConcurrentHashMap并没有在此方法上加上synchronized,首先判断value是否为null,如为null,则抛出NullPointerException,如不为null,则继续下面的步骤:

  和HashMap一样,首先对key.hashCode进行hash操作,得到key的hash值。Hash操作的算法和HashMap也不同。

  根据此hash值计算并获取其对应的数组中的Segment对象。

  在找到了数组中的Segment对象后,接着调用Segment对象的put方法来完成当前操作。

  当调用Segment对象的put方法时,首先进行lock操作,接着判断当前存储的对象个数加1后是否大于threshold。如果大于,则将当前的HashEntry对象数组大小扩大两倍,并将之前存储的对象重新hash,转移到新的对象数组中。

  ConcurrentHashMap基于concurrencyLevel划分出了多个Segment来对key-value进行存储,从而避免每次put操作都得锁住整个数组。在默认的情况下,最佳情况下,可以允许16个线程并发无阻塞的操作集合对象,尽可能地减少并发时的阻塞现象。

Remove(Object key):

  首先对key.hashCode进行hash操作,基于得到hash的值找到对应的Segment对象,调用其remove方法完成当前操作。

  Segment的remove方法进行加锁操作,操作完后,会释放锁。

  ConcurrentHashMap默认情况下,采用将数据分为16个段进行存储,并且16个段分别持有各自的锁,锁仅用于put和remove等改变集合对象的操作,读取数据不加锁。

时间: 2024-08-01 20:44:43

ConcurrentHashMap源码分析的相关文章

Hashtable、ConcurrentHashMap源码分析

Hashtable.ConcurrentHashMap源码分析 为什么把这两个数据结构对比分析呢,相信大家都明白.首先二者都是线程安全的,但是二者保证线程安全的方式却是不同的.废话不多说了,从源码的角度分析一下两者的异同,首先给出二者的继承关系图. Hashtable类属性和方法源码分析 我们还是先给出一张Hashtable类的属性和方法图,其中Entry<K,V>是Hashtable类的静态内部类,该类继承自Map.Entry<K,V>接口.如下将会详细讲解Hashtable类中

【源码阅读系列】JDK 8 ConcurrentHashMap 源码分析之 由transfer引发的bug

不阅读源码就不会发现这个事儿 前段时间在阅读ConcurrentHashMap源码,版本JDK 8,目前源码研究已经告一段落.感谢鲁道的ConcurrentHashMap源码分析文章,读到文章,感觉和作者发生了一些交流,解答了很多疑惑,也验证了一些想法.鲁道在简书的addCount分析文章点这里 (文章底部的评论中就有这篇文章发酵的原由).鲁道还有其他ConcurrentHashMap源码分析的系列文章,在简书.掘金都有分布,感兴趣的同学可以进一步追踪. 推完文章,回到本篇的主题"阅读源码&qu

死磕 java集合之ConcurrentHashMap源码分析(三)

本章接着上两章,链接直达: 死磕 java集合之ConcurrentHashMap源码分析(一) 死磕 java集合之ConcurrentHashMap源码分析(二) 删除元素 删除元素跟添加元素一样,都是先找到元素所在的桶,然后采用分段锁的思想锁住整个桶,再进行操作. public V remove(Object key) { // 调用替换节点方法 return replaceNode(key, null, null); } final V replaceNode(Object key, V

ConcurrentHashMap源码分析(JDK1.7和1.8对比)

一.ConcurrentHashMap简介 并发编程大师Doug Lea开发的并发容器之一.ConcurrentHashMap是线程安全且高效的HashMap,在HashMap的基础上增加了线程安全,当然结构方面也有所改变. 为什么要使用ConcurrentHashMap? 1.多线程环境下,HashMap会处于不安全状态.例如put操作可能会引起程序死循环,Cpu占有率达百分百,原因是多线程会导致HashMap的Entry链表形成环形数据结构,如此一来,他的next结点将永不为空,就会产生死循

死磕 java集合之ConcurrentHashMap源码分析(一)

开篇问题 (1)ConcurrentHashMap与HashMap的数据结构是否一样? (2)HashMap在多线程环境下何时会出现并发安全问题? (3)ConcurrentHashMap是怎么解决并发安全问题的? (4)ConcurrentHashMap使用了哪些锁? (5)ConcurrentHashMap的扩容是怎么进行的? (6)ConcurrentHashMap是否是强一致性的? (7)ConcurrentHashMap不能解决哪些问题? (8)ConcurrentHashMap中有哪

java基础系列之ConcurrentHashMap源码分析(基于jdk1.8)

1.前提 在阅读这篇博客之前,希望你对HashMap已经是有所理解的,否则可以参考这篇博客: jdk1.8源码分析-hashMap:另外你对java的cas操作也是有一定了解的,因为在这个类中大量使用到了cas相关的操作来保证线程安全的. 2.概述 ConcurrentHashMap这个类在java.lang.current包中,这个包中的类都是线程安全的.ConcurrentHashMap底层存储数据的结构与1.8的HashMap是一样的,都是数组+链表(或红黑树)的结构.在日常的开发中,我们

ConcurrentHashMap源码分析(JDK8版本&lt;转载&gt;)

注:本文源码是JDK8的版本,与之前的版本有较大差异 转载地址:http://blog.csdn.net/u010723709/article/details/48007881 ConcurrentHashMap是conccurrent家族中的一个类,由于它可以高效地支持并发操作,以及被广泛使用,经典的开源框架spring的底层数据结构就是使用ConcurrentHashMap实现的.与同是线程安全的老大哥HashTable相比,它已经更胜一筹,因此它的锁更加细化,而不是像HashTable一样

ConcurrentHashMap 源码分析

CocurrentHashMap 作用 HashTable通过对整张表加锁的方式实现并发hash查找与储存,CocurrentHashMapt通过Segment的方式可以实现相同的功能,不过效率更加高,在jdk1.6的时候,CocuentHashMap有弱一致性的问题,不过在jdk1.7的时候,这个问题已经修复了.所以是并发安全性还是性能都是非常高的.接下来我尝试基于jdk1.7的源码去分析CocurrentHashMap. cocurrentHashMap 初始化预处理 // Unsafe m

Java集合(15)--ConcurrentHashMap源码分析

ConcurrentHashMap使用了锁分离技术, 使用了多个锁来控制对hash表的不同部分进行的修改.使用段(Segment)来表示这些不同的部分,每个段其实就是一个小的hash table,它们有自己的锁.只要多个修改操作发生在不同的段上,它们就可以并发进行. 有些方法需要跨段,比如size()和containsValue(),它们可能需要锁定整个表而而不仅仅是某个段,这需要按顺序锁定所有段,操作完毕后,又按顺序释放所有段的锁. 段数组是final的,并且其成员变量实际上也是final的.