ConcurrentHashMap和HashMap的分析与理解

Wzt_blog

已于 2023-08-16 21:59:48 修改

阅读量170

点赞数

文章标签：哈希算法散列表算法

于 2023-08-16 17:32:38 首次发布

本文链接：https://blog.csdn.net/qq_42627388/article/details/132324473

版权

一、HashMap
HashMap在1.7的时候使用数组+链表，出现hash碰撞的时候使用头插法。使用头插法容易出现链表成环。链表主要解决hash碰撞的。如果HashMap上的元素超过0.75*数组大小则进行hash扩容。扩容大小为初始大小的2倍。至于为什么使用0.75是因为这个数是根据工业界和学术界验证的，即对时间和空间的均衡。如果负载因子过大，也就是长期不会扩容，查询时间会变长，如果负载因子过小，频繁的rehash，性能受到损失。
HashMap为解决出现环形链表，以及通过链表查询速度过慢的问题，在1.8的时候使用了数组链表+红黑树。但是还没有解决线程不安全的问题，即多线程在Put的时候出现覆盖或者丢失的问题。
丢失和覆盖的问题主要体现在：
1）丢失体现在，当两个线程A，B在put的时候，k,v不相同，两者计算的hash值对应的桶的位置都是5，AB同时插入，此时A的值可能丢失了。
2）覆盖则体现在两个线程A，B，对应的key相同但是value不同。AB同时操作，则出现了覆盖。

1.1HashMap扩容的机制
如果当put一个元素的时候先插入，如果当前hashMap中元素个数超过负载因子*初始化大小，然后进行扩容。扩容的大小为初始化大小的2倍，扩容完毕后，计算 newTab[e.hash & (newCap - 1)] = e;找到对应新数组的位置，完成数据的转移。

1.2HashMap的put方法
第一步：先计算当前key的hashCode异或hashCode高16位的hash值。（(key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16)）
第二步：计算tab[i = (n - 1) & hash]，找到对应的桶的位置。
第三步：如果桶中为null，则直接插入。
第四步：如果桶中已经有一个元素，并且该元素的键与待插入的键完全匹配（即哈希值和实际键值都相同），那么简单地更新该元素的值。
第五步：如果桶中首节点为红黑树节点，则将其添加或者替换当前节点。
第六步:如果为非红黑树节点，则将其按照链表进行处理，即完成添加或者替换，当链表中元素个数超过8，并且数组个数超过64的时候，会将链表转化为红黑树。
第七步：如果put后，发现数组中元素个数超过负载因子*数组大小的时候，先进行扩容，然后进行元素转移。

hashMap Put七步曲：（自研顺口溜）
计算key的hashCode值，与hash计算找位置。
位置为空直接插，位置不空判红黑，如果红黑则插替，非红黑链插替。
链转红黑要牢记，链长达八变红黑，六四大小是分界。
最后判断rehash，rehash过后需转移。

二、ConcurrentHashMap
为了保证在多线程操作下HashMap实现线程安全， Doug Lea编写了ConcurrentHashMap来实现线程的安全。
在jdk 1.7的时候使用16个Segment桶加Reentranlock来实现线程安全，也就是说ConcurrentHashMap中存在16把锁。每个segment相当于一个HashMap，在插入的时候，需要先定位到segment的位置，然后找到对应的桶。
在jdk1.8的时候使用数组链表+红黑树实现。多线程操作的安全性使用了cas+synchronized来实现线程的安全的。

2.1 Jdk1.8ConcurrentHashMap的put流程
第一步：先计算key的hashcode，再通过【spread】hash函数对hashCode取hash值。
第二步：定位bin，也就是数组位置。
如果table为空，完成初始化。

if (tab == null || (n = tab.length) == 0)
    tab = initTable();

第三步：如果非空，CAS 插入或锁定 bin：
如果bin为空，直接插入

if (casTabAt(tab, i, null,
             new Node<K,V>(hash, key, value, null)))
    break;

第四步：如果CAS 插入失败，则判断当前是否出现扩容，如果扩容的话，帮助数据迁移。
第五步：如果不是在扩容，使用synchronzied完成插入或者覆盖，这里设计到先判断是否为链表，然后判断当前节点是否为红黑树。插入后，判断是否需要将链表转化为红黑树，也就是链表元素个数超过8个时候，并且数组的长度为64 的时候，将其转化为红黑树。
为什么要先扩容，再转化为红黑树呢？
主要是因为降低Hash碰撞，减少链表的长度。
[图片]

Segment初始化：
Segment数组的长度ssize是通过concurrentLevel的计算出来的，具体而言，先判断concurrentLevel是否超过了最大的数组大小，然后通过ssize<concurrencyLevel比较大小计算出ssize。在初始化的时候sszie为1，如果ssize<<=1没有大于concurrentLevel，则一直while循环计算，比如说concurrentLevel为5，则计算出的sszie为8。

public class ConcurrentHashMapDemo {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        int concurrencyLevel=sc.nextInt();
        int ssize=1;
        while(ssize<concurrencyLevel){
            ssize<<=1;
        }
        System.out.println(ssize);
    }
}

三、对比jdk1.8 HashMap和ConcurrentHashMap 的put方法。
在put的时候HashMap在判断bin当前节点类型的时候，先判断是否为红黑树，而ConcurrentHashMap 会先判断当前节点是否为链表，这里的主要原因是因为，HashMap是线程不安全的，在操作的时候追求查找的性能，因此先判断是否为红黑树，而ConcurrentHashMap 的话，是在多线程操作下的一种工具类，主要追求的是并发和性能，不太想把链表转化为红黑树，因此先判断链表。
GPT的解释

设计目标:
HashMap: 非线程安全，主要用于单线程场景，关心的是性能。
ConcurrentHashMap: 线程安全，用于多线程场景，关心的是性能和并发。
检查的顺序:
在 HashMap 中，桶中的链表转为红黑树是一个重要的性能优化点。所以，在进行节点查找时，如果是红黑树结构，那么利用其 O(log n) 的查找时间复杂度是很关键的。所以它会先检查是否是红黑树。
ConcurrentHashMap 则是设计用于高并发的场景。在这种场景下，结构转换（链表到红黑树）的情况比较少见，因为每个桶的节点数量往往会被并发地分散到多个桶中。因此，它期望更多地遇到链表结构，所以先检查是否是链表。
线程安全性:
ConcurrentHashMap 需要在多线程环境中保持线程安全。考虑到在高并发下，桶的结构从链表转为红黑树的概率较小，因此它的设计决策可能是优先处理最常见的场景，即链表的场景

四、为何扩容为2^n？在定位桶位置的时候没有使用hash值模数组大小？为何在计算hash的时候hashCode移动高16位？

第一个答案：通过(2^n - 1) & hash公式计算出来的槽位索引更具散列性，如果为其他元素的话，k,v都聚集在几个桶上。

第二个答案：&运算效率高，hashCode值太大，散裂性不强。

第三个答案：使得高位参与运算，提高散列性。

五、如果有10亿数据，如何使用HashMap存储？
1）预分配大小，避免频繁rehash。
2）让多个线程分别处理不同的桶。