【hashmap】HashMap原理及线程不安全详解|哈希表原理

bandaoyu

已于 2022-07-27 16:34:30 修改

阅读量2.8k

点赞数 1

分类专栏：数据结构|算法|设计模式文章标签：散列表哈希算法数据结构

于 2020-08-18 17:08:47 首次发布

本文链接：https://blog.csdn.net/bandaoyu/article/details/108082194

版权

数据结构|算法|设计模式专栏收录该内容

53 篇文章 4 订阅

订阅专栏

本文详细解析了HashMap、HashTable和ConcurrentHashMap的区别，探讨了HashMap的工作原理，包括put和get方法的流程，扩容机制，以及线程安全性问题。文章还讨论了哈希算法、哈希冲突处理和加载因子的影响。

摘要由CSDN通过智能技术生成

HashMap和HashTable区别（HashTable线程安全）

HashTable

HashMap

ConcurrentHashMap （已经放弃）

HashMap和HashTable区别（HashTable线程安全）

HashTable

底层数组+链表实现，无论key还是value都不能为null，线程安全，实现线程安全的方式是在修改数据时锁住整个HashTable，效率低，ConcurrentHashMap做了相关优化
初始size为11，扩容：newsize = oldsize*2+1
计算index的方法：index = (hash & 0x7FFFFFFF) % tab.length

HashMap

底层数组+链表实现，可以存储null键和null值，线程不安全
初始size为16，扩容：newsize = oldsize*2，size一定为2的n次幂
扩容针对整个Map，每次扩容时，原来数组中的元素依次重新计算存放位置，并重新插入
插入元素后才判断该不该扩容，有可能无效扩容（插入后如果扩容，如果没有再次插入，就会产生无效扩容）
当Map中元素总数超过Entry数组的75%，触发扩容操作，为了减少链表长度，元素分配更均匀
计算index方法：index = hash & (tab.length – 1)

HashMap的初始值还要考虑加载因子:

哈希冲突：若干Key的哈希值按数组大小取模后，如果落在同一个数组下标上，将组成一条Entry链，对Key的查找需要遍历Entry链上的每个元素执行equals()比较。

加载因子：为了降低哈希冲突的概率，默认当HashMap中的键值对达到数组大小的75%时，即会触发扩容。因此，如果预估容量是100，即需要设定100/0.75＝134的数组大小。

空间换时间：如果希望加快Key查找的时间，还可以进一步降低加载因子，加大初始大小，以降低哈希冲突的概率。

ConcurrentHashMap （已经放弃）

底层采用分段的数组+链表实现，线程安全
通过把整个Map分为N个Segment，可以提供相同的线程安全，但是效率提升N倍，默认提升16倍。(读操作不加锁，由于HashEntry的value变量是 volatile的，也能保证读取到最新的值。)
Hashtable的synchronized是针对整张Hash表的，即每次锁住整张表让线程独占，ConcurrentHashMap允许多个修改操作并发进行，其关键在于使用了锁分离技术
有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁
扩容：段内扩容（段内元素超过该段对应Entry数组长度的75%触发扩容，不会对整个Map进行扩容），插入前检测需不需要扩容，有效避免无效扩容

HashMap原理

（更通俗的解释：最通俗易懂搞定HashMap的底层原理 - 知乎）

HashMap的数据结构：

HashMap的数据结构为 数组+(链表或红黑树)，上图

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

1、put方法原理（存储过程）

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

index = Hash（“apple”）-----Hash中哈希函数计算出hashcode，再用取模（hashcode/数组长度）等方法得到index

假定最后计算出的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被查找的可能性更大。

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算法的结果就是均匀的。

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带有环形链表，所以程序将会进入死循环！

原文：HashMap原理及线程不安全详解 - https://my.oschina.net/muziH/blog/1596801

解释2：Java HashMap的死循环 https://coolshell.cn/articles/9606.html

哈希表原理：

哈希表的原理及实现代码 - https://www.cnblogs.com/time-read/p/10716403.html

Hashmap

1、hashmap的数据结构

Hashmap实际上是一个数组和链表的结合体（在数据结构中，一般称之为“链表散列“），请看下图（横排表示数组，纵排表示数组元素【实际上是一个链表】）。

2、hash算法

我们可以看到在hashmap中要找到某个元素，需要根据key的hash值来求得对应数组中的位置。如何计算这个位置就是hash算法。

希望这个hashmap里面的元素位置尽量的分布均匀些，hashcode对数组长度取模运算分布比较均匀，但是，“模”运算的消耗大，用与的方式：

static int indexFor(int h, int length)
 {        
 return h & (length-1);     
}

3、hashmap的resize

当hashmap中的元素个数超过数组大小*loadFactor时，就会进行数组扩容，loadFactor的默认值为0.75，超过这个阈值，扩大一倍。

预设元素的个数能够有效的提高hashmap的性能。比如说，我们有1000个元素new HashMap(1000), 但是理论上来讲new HashMap(1024)更合适，不过上面annegu已经说过，即使是1000，hashmap也自动会将其设置为1024。但是new HashMap(1024)还不是更合适的，因为0.75*1000 < 1000, 也就是说为了让0.75 * size > 1000, 我们必须这样new HashMap(2048)才最合适，既考虑了&的问题，也避免了resize的问题。

4、key的hashcode与equals方法改写

（在设计一个类的时候，很可能需要重写类的hashCode（）方法，此外，在集合HashSet的使用上，我们也需要重写hashCode方法来判断集合元素是否相等。）

get方法的过程：首先计算key的hashcode，找到数组中对应位置的某一元素，然后通过key的equals方法在对应位置的链表中找到需要的元素。

所以，hashcode与equals方法对于找到对应元素是两个关键方法。

Hashmap的key可以是任何类型的对象，例如User这种对象，为了保证两个具有相同属性的user的hashcode相同，我们就需要改写hashcode方法，比方把hashcode值的计算与User对象的id关联起来，那么只要user对象拥有相同id，那么他们的hashcode也能保持一致了，这样就可以找到在hashmap数组中的位置了。如果这个位置上有多个元素，还需要用key的equals方法在对应位置的链表中找到需要的元素，所以只改写了hashcode方法是不够的，equals方法也是需要改写滴~当然啦，按正常思维逻辑，equals方法一般都会根据实际的业务内容来定义，例如根据user对象的id来判断两个user是否相等。

hashCode（）方法的基本规则：

· 在程序运行过程中，同一个对象多次调用hashCode（）方法应该返回相同的值。

· 当两个对象通过equals（）方法比较返回true时，则两个对象的hashCode（）方法返回相等的值。

· 对象用作equals（）方法比较标准的Field，都应该用来计算hashCode值。

在改写equals方法的时候，需要满足以下三点：
(1) 自反性：就是说a.equals(a)必须为true。
(2) 对称性：就是说a.equals(b)=true的话，b.equals(a)也必须为true。
(3) 传递性：就是说a.equals(b)=true，并且b.equals(c)=true的话，a.equals(c)也必须为true。
通过改写key对象的equals和hashcode方法，我们可以将任意的业务对象作为map的key(前提是你确实有这样的需要)。

HashMap的扩容机制---resize() - https://www.cnblogs.com/williamjie/p/9358291.html

《HashMap中的为什么hash的长度为2的幂而&位必须为奇数》

https://blog.csdn.net/zjcjava/article/details/78495416

《Java如何计算hashcode值》https://www.cnblogs.com/hehe520/p/6329996.html