HashMap原理及线程不安全详解

最新推荐文章于 2024-07-10 22:41:59 发布

weixin_34228617

最新推荐文章于 2024-07-10 22:41:59 发布

阅读量415

点赞数 2

文章标签：数据结构与算法 java

原文链接：https://my.oschina.net/muziH/blog/1596801

版权

为什么80%的码农都做不了架构师？>>>

一、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操作：