深入理解hashmap底层实现原理

桃扇骨 2024-03-17 10:05 70阅读 0赞

**目录**

总体介绍

HashMap元素的存储

在hashmap中添加元素

HashMap的扩容机制

HashMap的线程安全性

1.添加和删除元素时存在不安全性

2.进行扩容操作时存在不安全性

3.哈希冲突存在不安全性

4.线程之间的不可见性导致安全问题

--------------------

## 总体介绍 ##

![22f91ed0fea64f44be5a65842b2c954d.png][]

> HashMap**是我们用于元素映射使用频率最高的数据结构，它继承自AbstractList类，并且支持一条值为null的Key和无数条value为null的数据，**HashMap**是线程不安全的6在多线程环境下我们通过使用Collections中的synchronizedMap使其具有线程安全的能力或者直接使ConcurrentHashMap,随着JDK的更新迭代，自jdk1.8以来，**HashMap**的底层数据结构已经发展为数组+链表+红黑树**

## HashMap元素的存储 ##

![2a26e21b9e6646c2959e1bc7226c4a46.png][]

HashMap底层使用Node<K,V>进行元素的存储，我们查看其源码：

static class Node<K,V> implements Map.Entry<K,V> {
            final int hash;    //用来定位数组索引位置
            final K key;
            V value;
            Node<K,V> next;   //链表的下一个node
    
            Node(int hash, K key, V value, Node<K,V> next) { ... }
            public final K getKey(){ ... }
            public final V getValue() { ... }
            public final String toString() { ... }
            public final int hashCode() { ... }
            public final V setValue(V newValue) { ... }
            public final boolean equals(Object o) { ... }
    }

> **在**HashMap**的源码中，一个比较重要的组成部分是Node\[\]table,即哈希桶数组，元素根据哈希算法最终被放入哈希桶不同下标的位置中，随着元素的不断增多，可能存在两个不同的元素有相同的下标，这便是哈希冲突，哈希桶解决哈希冲突的方法是链式地址法，所谓链式地址法，是指通过采用链表+数组的方式解决哈希冲突问题，随着哈希桶内元素的不断增加，当单个链表元素数量大于等于8以及哈希桶中的总元素数量>=64时，链表就会转化为红黑树**

## 在hashmap中添加元素 ##

![3b54ba79e5d64c20b63883cb30a366be.png][]

在HashMap中添加元素的逻辑如下：

> **1.判断数组table\[i\]是否为空，如果是空，则执行resize()进行扩容**
> 
> **2.根据键值key计算hash值得到应该插入的数组索引i，如果table\[i\]==null,直接创建新结点并加入数组，转向6；如果table\[i\]对应的元素不为空，转向3**
> 
> **3.判断table\[i\]首个元素是否与我们插入的元素完全相同（根据hashcode()以及equals()进行判断），如果相同直接覆盖value，否则转向4**
> 
> **4.判断table\[i\]是否是treeNode，即table\[i\]是否是红黑树，如果是红黑树，则直接在红黑树中插入键值对，否则转向5**
> 
> **5.遍历table\[i\],判断链表的长度是否大于等于8，如果满足条件直接把链表转化为红黑树，否则在链表中插入元素，遍历链表的过程中如果发现相同的key直接覆盖value即可**
> 
> **6.扩容成功后，判断实际存在的键值对数量size是否超过了最大容量threshold，如果超过直接进行扩容**

HashMap中的源码如下：

> **1 public V put(K key, V value) \{  
> 2 // 对key的hashCode()做hash  
> 3 return putVal(hash(key), key, value, false, true);  
> 4 \}  
> 5  
> 6 final V putVal(int hash, K key, V value, boolean onlyIfAbsent,  
> 7 boolean evict) \{  
> 8 Node<K,V>\[\] tab; Node<K,V> p; int n, i;  
> 9 // 步骤①：tab为空则创建  
> 10 if ((tab = table) == null || (n = tab.length) == 0)  
> 11 n = (tab = resize()).length;  
> 12 // 步骤②：计算index，并对null做处理  
> 13 if ((p = tab\[i = (n - 1) & hash\]) == null)  
> 14 tab\[i\] = newNode(hash, key, value, null);  
> 15 else \{  
> 16 Node<K,V> e; K k;  
> 17 // 步骤③：节点key存在，直接覆盖value  
> 18 if (p.hash == hash &&  
> 19 ((k = p.key) == key || (key != null && key.equals(k))))  
> 20 e = p;  
> 21 // 步骤④：判断该链为红黑树  
> 22 else if (p instanceof TreeNode)  
> 23 e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);  
> 24 // 步骤⑤：该链为链表  
> 25 else \{  
> 26 for (int binCount = 0; ; ++binCount) \{  
> 27 if ((e = p.next) == null) \{  
> 28 p.next = newNode(hash, key,value,null);  
> //链表长度大于8转换为红黑树进行处理  
> 29 if (binCount >= TREEIFY\_THRESHOLD - 1) // -1 for 1st  
> 30 treeifyBin(tab, hash);  
> 31 break;  
> 32 \}  
> // key已经存在直接覆盖value  
> 33 if (e.hash == hash &&  
> 34 ((k = e.key) == key || (key != null && key.equals(k)))) break;  
> 36 p = e;  
> 37 \}  
> 38 \}  
> 39  
> 40 if (e != null) \{ // existing mapping for key  
> 41 V oldValue = e.value;  
> 42 if (!onlyIfAbsent || oldValue == null)  
> 43 e.value = value;  
> 44 afterNodeAccess(e);  
> 45 return oldValue;  
> 46 \}  
> 47 \}**
> 
> **48 ++modCount;  
> 49 // 步骤⑥：超过最大容量 就扩容  
> 50 if (++size > threshold)  
> 51 resize();  
> 52 afterNodeInsertion(evict);  
> 53 return null;  
> 54 \}**

## HashMap的扩容机制 ##

与JDK 1.7相比，JDK1.8在原来扩容的基础上添加了红黑树，其实现的流程和条件如下：当满足扩容条件时，进行扩容操作(哈希表中的元素个数达到threshold)，进行扩容操作时如果发现满足树化的条件（单条链表元素数量>=8&&哈希桶中存储的总元素的数量>=64）则将链表转化为红黑树。

具体的源码及分析如下：

final Node<K,V>[] resize() {
            Node<K,V>[] oldTab = table;
            int oldCap = (oldTab == null) ? 0 : oldTab.length;
            int oldThr = threshold;
            int newCap, newThr = 0;
            if (oldCap > 0) {
                if (oldCap >= MAXIMUM_CAPACITY) {
                    threshold = Integer.MAX_VALUE;
                    return oldTab;//超过了哈希表的最大容量不进行扩容，任由其碰撞
                }
                else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                         oldCap >= DEFAULT_INITIAL_CAPACITY)//数组容量扩大为两倍
                    newThr = oldThr << 1; // 将临界值扩大为两倍
            }
            else if (oldThr > 0) // initial capacity was placed in threshold
                newCap = oldThr;
            else {               // zero initial threshold signifies using defaults
                newCap = DEFAULT_INITIAL_CAPACITY;//初始化容量
                newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);//初始化扩容门槛
            }
            if (newThr == 0) {
                float ft = (float)newCap * loadFactor;
                newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                          (int)ft : Integer.MAX_VALUE);
            }
            threshold = newThr;
            @SuppressWarnings({"rawtypes","unchecked"})
            Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
            table = newTab;
            if (oldTab != null) {
                for (int j = 0; j < oldCap; ++j) {
                    Node<K,V> e;
                    if ((e = oldTab[j]) != null) {
                        oldTab[j] = null;
                        if (e.next == null)
                            newTab[e.hash & (newCap - 1)] = e;
                        else if (e instanceof TreeNode)
                            ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
                        else { // preserve order
                            Node<K,V> loHead = null, loTail = null;
                            Node<K,V> hiHead = null, hiTail = null;
                            Node<K,V> next;
                            do {
                                next = e.next;
                                //新索引=原索引
                                if ((e.hash & oldCap) == 0) {
                                    if (loTail == null)
                                        loHead = e;
                                    else
                                        loTail.next = e;
                                    loTail = e;
                                }
                                else {
                                    //新的索引=原索引+oldCap
                                    if (hiTail == null)
                                        hiHead = e;
                                    else
                                        hiTail.next = e;
                                    hiTail = e;
                                }
                            } while ((e = next) != null);
                            //原索引放入bucket
                            if (loTail != null) {
                                loTail.next = null;
                                newTab[j] = loHead;
                            }
                            //新索引放入bucket
                            if (hiTail != null) {
                                hiTail.next = null;
                                newTab[j + oldCap] = hiHead;
                            }
                        }
                    }
                }
            }
            return newTab;
        }

##  ##

> **除此之外，我们通过查看resize()的源码，我们可以发现JDK1.8对扩容之后元素的索引变化也是有一定的优化：经过观测可以发现，我们使用的是2次幂的扩展(指长度扩为原来2倍)，所以，元素的位置要么是在原位置，要么是在原位置再移动2次幂的位置。看下图可以明白这句话的意思，n为table的长度，图（a）表示扩容前的key1和key2两种key确定索引位置的示例，图（b）表示扩容后key1和key2两种key确定索引位置的示例，其中hash1是key1对应的哈希与高位运算结果。**

![2db0f7872ea54dbaab1b848e9747eb72.png][]

> **元素在重新计算hash之后，因为n变为2倍，那么n-1的mask范围在高位多1bit(红色)，因此新的index就会发生这样的变化：**

![792cad6d52c447888dbd60e4a7257ed7.png][]

> **因此，我们在扩充HashMap的时候，不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了，是0的话索引没变，是1的话索引变成“原索引+oldCap”，可以看看下图为16扩充为32的resize示意图**：

![3ff577c26c6b4875bc322e3ea9ad6684.png][]

>  **这个设计可以说是相当巧妙了，既省略了类似JDK1.7的扩容之后重新计算hash的这样一个过程，提升了效率；除此之外，由于我们新增的一位是1还是0完全是随机的，所以可以把之前存在哈希冲突的结点有效的均匀分散到新的bucket中了。**

## HashMap的线程安全性 ##

**hashmap的线程不安全性主要体现在下面四个方面：**

#### 1.添加和删除元素时存在不安全性 ####

> **在并发环境下，如果多个线程同时对HashMap进行修改操作，例如：添加、删除或修改元素，可能会导致数据结构出现冲突，最终可能会导致数据不一致或丢失。**
> 
> **这是因为多个线程在同一时间可能会尝试修改同一个桶(bucket)中的数据，而在修改过程中，可能会丢失某些数据或者覆盖其他线程修改的数据，从而导致数据不一致。**

![a94e5b4fced448b79efeec9b45b96e6b.png][]

#### 2.进行扩容操作时存在不安全性 ####

> **HashMap 在达到一定容量时需要进行扩容，扩容过程需要重新计算哈希值，重新分配存储位置等操作。如果在扩容过程中有多个线程同时进行插入或删除操作，就可能导致数据结构混乱，甚至死循环等问题。**

#### 3.哈希冲突存在不安全性 ####

> **在对数组进行插入或删除操作时，可能会出现 Hash 冲突，即不同的键值对可能会被映射到数组的同一个位置上，这就需要通过链表或红黑树来解决冲突。**
> 
> **而当多个线程同时进行插入或删除操作时，可能会导致链表或红黑树的结构被破坏，从而导致数据丢失或出现异常。**

#### 4.线程之间的不可见性导致安全问题 ####

> **由于 HashMap 不是线程安全的，因此多个线程可能会同时访问同一个 HashMap 实例。**
> 
> **而当一个线程对 HashMap 进行修改时，其他线程可能无法立即看到这些修改，这就可能导致数据不一致的问题。**
> 
> **为了解决 HashMap 的线程安全问题，可以使用 ConcurrentHashMap，它使用了锁分段技术、CAS、 volatile 变量来保证线程安全和数据可见性。**
> 
> **但是，这些技术也会带来一些额外的开销，所以在非高并发场景下，HashMap可能会比ConcurrentHashMap更快。**

[22f91ed0fea64f44be5a65842b2c954d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/b10097b7ef5548f58f60cafca071f992.png
[2a26e21b9e6646c2959e1bc7226c4a46.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/b027569275ed41ee89c0af798ab750e0.png
[3b54ba79e5d64c20b63883cb30a366be.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/3176339f6f084ab489d8949efbcf3337.png
[2db0f7872ea54dbaab1b848e9747eb72.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/2089867c86d14bcaac2401e3d7a33bbb.png
[792cad6d52c447888dbd60e4a7257ed7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/3af762078e1a4225b6e508082f9c2c00.png
[3ff577c26c6b4875bc322e3ea9ad6684.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/a3a64340db8c404586c8c8a72535b3fd.png
[a94e5b4fced448b79efeec9b45b96e6b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/17/a0126d92e1374b1dbd665a25203c0309.png