文档章节

HashMap原理及线程不安全详解

木子SMZ
 木子SMZ
发布于 2017/12/29 17:50
字数 1910
阅读 159
收藏 1

一、HashMap

HashMap是一个用于存储Key-Value键值对的集合,每一个键值对也叫做Entry。这些个键值对(Entry)分散存储在一个数组当中,数组初始化长度为16,数组中的每一个元素初始值都是null,这个数组就是HashMap的主干。

1、put方法原理

当调用hashMap.put("apple", 0) ,插入一个Key为“apple"的元素。这时候我们需要利用一个哈希函数来确定Entry的插入位置(index):

index =  Hash(“apple”)

假定最后计算出的index是2,那么结果如下:

但是,因为HashMap的长度是有限的,当插入的Entry越来越多时,再完美的Hash函数也难免会出现index冲突的情况。比如下面这样:

HashMap数组的每一个元素不止是一个Entry对象,也是一个链表的头节点。每一个Entry对象通过Next指针指向它的下一个Entry节点。当新来的Entry映射到冲突的数组位置时,只需要插入到对应的链表即可:

需要注意的是,新来的Entry节点插入链表时,使用的是“头插法”。 原因时HashMap的设计者认为后插入的元素被get的几率更大。

        2、get方法原理

使用Get方法根据Key来查找Value的时候,发生了什么呢?

首先会把输入的Key做一次Hash映射,得到对应的index:

index =  Hash(“apple”)

由于刚才所说的Hash冲突,同一个位置有可能匹配到多个Entry,这时候就需要顺着对应链表的头节点,一个一个向下来查找。假设我们要查找的Key是“apple”:

第一步,我们查看的是头节点Entry6,Entry6的Key是banana,显然不是我们要找的结果。

第二步,我们查看的是Next节点Entry1,Entry1的Key是apple,正是我们要找的结果。

之所以把Entry6放在头节点,是因为HashMap的发明者认为,后插入的Entry被查找的可能性更大。

 

3、HashMap 扩容(resize)

HashMap的默认初始长度时16,并且每次自动扩展或者手动初始化时,长度必须时2的幂。原因在于HashMap的数组下标算法,当put一个值时,会首先计算出hash code,根据hash code决定放在数组的位置,考虑效率问题并没有采用取模的方式,而是采用按位与的方式

下面我们以“book"的Key来演示整个过程:

1.计算book的hashcode,结果为十进制的3029737,二进制的101110001110101110 1001。

2.假定HashMap长度是默认的16,计算Length-1的结果为十进制的15,二进制的1111。

3.把以上两个结果做与运算,101110001110101110 1001 & 1111 = 1001,十进制是9,所以 index=9。

可以说,Hash算法最终得到的index结果,完全取决于Key的Hashcode值的最后几位。

在这种情况下,如果数字的长度不是2的幂,会发生以下结果:

假设HashMap的长度是10,重复刚才的运算步骤:

单独看这个结果,表面上并没有问题。我们再来尝试一个新的HashCode  101110001110101110 1011 :

让我们再换一个HashCode 101110001110101110 1111 试试  :

虽然HashCode的倒数第二第三位从0变成了1,但是运算的结果都是1001。也就是说,当HashMap长度为10的时候,有些index结果的出现几率会更大,而有些index结果永远不会出现(比如0111)! 这样,显然不符合Hash算法均匀分布的原则。 反观长度16或者其他2的幂,Length-1的值是所有二进制位全为1,这种情况下,index的结果等同于HashCode后几位的值。只要输入的HashCode本身分布均匀,Hash算法的结果就是均匀的。

3、HashMap的高并发问题

HashMap是线程不安全的,原因就在于HashMap的rehash。rehash是HashMap扩容过程种的一个步骤。 HashMap的容量是有限的。当经过多次元素插入,使得HashMap达到一定饱和度时,Key映射位置发生冲突的几率会逐渐提高。 这时候,HashMap需要扩展它的长度,也就是进行Resize。 影响发生Resize的因素有两个:

1.Capacity

HashMap的当前长度。上一期曾经说过,HashMap的长度是2的幂。

2.LoadFactor

HashMap负载因子,默认值为0.75f。

衡量HashMap是否进行Resize的条件如下:

HashMap.Size   >=  Capacity * LoadFactor

 

HashMap的扩容主要分为两步:

1.扩容

创建一个新的Entry空数组,长度是原数组的2

2.ReHash

遍历原Entry数组,把所有的Entry重新Hash到新数组。为什么要重新Hash呢?因为长度扩大以后,Hash的规则也随之改变。

让我们回顾一下Hash公式:

index =  HashCode(Key) &  (Length - 1)

当原数组长度为8时,Hash运算是和111B做与运算;新数组长度为16,Hash运算是和1111B做与运算。Hash结果显然不同。

ReHash的Java代码如下:

/**
 * Transfers all entries from current table to newTable.
 */
void transfer(Entry[] newTable, boolean rehash) {
    int newCapacity = newTable.length;
    for (Entry<K,V> e : table) {
        while(null != e) {
            Entry<K,V> next = e.next;
            if (rehash) {
                e.hash = null == e.key ? 0 : hash(e.key);
            }
            int i = indexFor(e.hash, newCapacity);
            e.next = newTable[i];
            newTable[i] = e;
            e = next;
        }
    }
}

以上过程单线程下不会出现问题,但是当两个线程同时触发resize的时候就有可能出现问题

假设一个HashMap已经到了Resize的临界点。此时有两个线程A和B,在同一时刻对HashMap进行Put操作:

此时达到Resize条件,两个线程各自进行Rezie的第一步,也就是扩容:

这时候,两个线程都走到了ReHash的步骤。让我们回顾一下ReHash的代码:

假如此时线程B遍历到Entry3对象,刚执行完红框里的这行代码,线程就被挂起。对于线程B来说:

e = Entry3

next = Entry2

这时候线程A畅通无阻地进行着Rehash,当ReHash完成后,结果如下(图中的e和next,代表线程B的两个引用):

直到这一步,看起来没什么毛病。接下来线程B恢复,继续执行属于它自己的ReHash。线程B刚才的状态是:

e = Entry3

next = Entry2

当执行到上面这一行时,显然 i = 3,因为刚才线程A对于Entry3的hash结果也是3。

我们继续执行到这两行,Entry3放入了线程B的数组下标为3的位置,并且e指向了Entry2。此时e和next的指向如下:

e = Entry2

next = Entry2

整体情况如图所示:

接着是新一轮循环,又执行到红框内的代码行:

e = Entry2

next = Entry3

整体情况如图所示:

接下来执行下面的三行,用头插法把Entry2插入到了线程B的数组的头结点:

整体情况如图所示:

第三次循环开始,又执行到红框的代码:

e = Entry3

next = Entry3.next = null

最后一步,当我们执行下面这一行的时候,见证奇迹的时刻来临了:

newTable[i] = Entry2

e = Entry3

Entry2.next = Entry3

Entry3.next = Entry2

链表出现了环形!

整体情况如图所示:

此时,问题还没有直接产生。当调用Get查找一个不存在的Key,而这个Key的Hash结果恰好等于3的时候,由于位置3带有环形链表,所以程序将会进入死循环!

© 著作权归作者所有

木子SMZ
粉丝 2
博文 34
码字总数 22804
作品 0
昌平
程序员
私信 提问
Java容器源码分析-HashMap vs TreeMap vs LinkedHashMap

这里我采用的分析方式是帖子博客加上自己翻看jdk源码。有些情况下写一些测试的算法小例子加深印象。我这里只描述一下自己的总结想法 上一篇文章我们研究了set接口下的几个容器,由于其Set集合...

贾浩v
2017/10/19
0
0
后台开发常问面试题集锦(问题搬运工,附链接)

Java基础问题 String的’+’的性能及原理 java之yield(),sleep(),wait()区别详解-备忘笔记 深入理解Java Stream流水线 抽象 & abstract关键字 Java final 修饰符知识点总结(必看篇) Java中的...

大黄有故事
2017/11/18
0
0
并发安全的 ConcurrentHashMap 实现原理详解

并发安全的 ConcurrentHashMap 实现原理详解 哈希表是中非常高效,复杂度为O(1)的数据结构,在Java开发中,我们最常见到最频繁使用的就是HashMap和HashTable,但是在线程竞争激烈的并发场景中...

程序员诗人
2017/08/25
0
0
java.util包中集合详解

本文只是集合的概述,介绍集合之间的关系,以及各种集合的异同,不会深入介绍具体的实现,具体实现的介绍,可以参见文中提供的链接。 java集合概述 java集合整体分为collection和map两种,接...

jacksu在简书
2018/01/25
0
0
ConcurrentHashMap 详解一

本文代码来自JDK8 ConcurrentHashMap 实现了线程安全; 虽然可以通过 Hashtable 或者 Collections.synchronizedMap 来生成一个线程安全的 Map 实例, 但这是全局锁方式, 性能不行; ConcurrentH...

希灵深渊
2018/11/28
0
0

没有更多内容

加载失败,请刷新页面

加载更多

聊聊spring cloud的ConsulServiceRegistry

序 本文主要研究一下spring cloud的ConsulServiceRegistry ServiceRegistry spring-cloud-commons-2.1.2.RELEASE-sources.jar!/org/springframework/cloud/client/serviceregistry/ServiceR......

go4it
昨天
1
0
Nextjs 学习 —— hooks

22

lemos
昨天
1
0
如何在spring mvc restful接口中定制化类型转换和格式化

1.痛点 最近小胖哥搞了个小程序,有几个spring mvc 接口传递了时间,时间用java 8 time 相关的api 来直接接收: 当使用根据ISO 8601格式化的参数向任何这些方法发送POST请求时,报出了如下异...

码农小胖哥
昨天
2
0
docker日志监控

日志处理机制 我们先来了解一下docker日志处理的机制,当启动一个容器的时候,它其实是docker daemon的一个子进程,docker daemon可以拿到你容器里面进程的标准输出,拿到标准输出后,它会通...

爱宝贝丶
昨天
2
0
域名已备案,但jsapi添加支付授权目录依然提示支付授权目录未通过ICP备案!!!

问题描述: 一网站域名xxx.cn已备案成功,在全国工业和信息化部(http://beian.miit.gov.cn/publish/query/indexFirst.action)查询到备案成功的,但是在微信商户平台配置jsapi添加支付授权目录...

闊苡訆涐囍醣
昨天
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部