在Java中，HashMap中是用哪些方法来解决哈希冲突的？

来看一道题,问HashMap是用下列哪种方法来解决哈希冲突的?

A 开放地址法
B 二次哈希法
C 链地址法
D 建立一个公共溢出区

答案是:C

解决哈希冲突的方法有三种,分别是:

•  开放地址法:寻找下一个为空的数组下标,而后将冲突元素存储
• 再散列法(二次哈希法):再次使用一个不同的哈希算法再计算一次 (第一次%16换另一个数进行%运算)
• 链地址法(拉链法):将所有冲突元素按照链表存储,冲突后时间复杂度变为O(1+n)n为冲突元素个数)[hashMap就是用这种方法]

首先来了解一下什么是哈希表

哈希表是以(Key,Value):数值的形式存储数据的

根据相应的哈希算法计算key,返回值即为V存储的数组下标

哈希算法:f(K) --- . int即为V需要存储的数组下标

为什么会造成哈希冲突呢?

用一个数去模运算,取得余数就是所要存储数组数据的下标,但是余数可能会存在一样的,这样就导致一样余数的户数无处存储,所以就造成了哈希冲突.

哈希冲突解决思路:

哈希算法计算的两个不同对象的哈希值相等的情况

eg:1 % 16 == 17 % 16[1和17是不同的key值]--->就是哈希冲突了

HashMap中用链地址法来解决 

HashMap源码解析(负载因子,树化策略,内部hash实现,resize策略...)

HashMap中的内部属性:

• 负载因子:final loadFactor (默认为0.75f)
• 实际容量: int threshold = loadFactor * tab.length
• 树化阈值:int TREEIFY_THRESHOLD = 8;
• 解除树化阈值: int UNTREEIFY_THRESHOLD = 6;
• HashMap也采用了懒加载策略,第一次put时初始化哈希表
• 树化逻辑:索引下标对应的链表长度达到阈值8并且当前哈希表长度达到64才不会树化,否则只是调用resize()方法进行哈希表扩容
• resize();扩容为原先数组的2倍

负载因子大小怎么决定?

负载因子过大会导致哈希冲突明显增加,节省内存

负载因子过小会导致哈希表频繁扩容,内存利用率低

 默认0.75,0.75是一个经过计算得出的值,即能保证哈希冲突不会太严重也能保证效率不会太低

源码: 

public V put(K key, V value) {
    return putVal(hash(key), key, value, false, true);
}

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

可以发现源码中并没有直接使用Object中的hashCode方法,而是再让h无符号右移了16位

为何不直接使用Object提供的hashCode?

为了将哈希码保留一半,将高低位都参与运算,减少内存开销,减少哈希冲突

直接使用会造成空间浪费

(h = key.hashCode()) ^ (h >>> 16); //32 --->16 保留一半(原本32右移16位去掉了一半)

put内部逻辑:

 

1.哈希表索引下标计算:

i = (n-1) & hash   //与运算

保证求出的索引下标都在哈希表的长度范围之内

2.n为哈希表的长度

n必须为2 的n次方,保证哈希表中的所有索引下标都会被访问到

若n=15,则以下位置永远不可能存储元素

0011,0101,1001,1011,1101,1111

接下来再看源码:

final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
               boolean evict) {
    Node<K,V>[] tab; Node<K,V> p; int n, i;
//第一次put值的时候将哈希表初始化
//resize():1,完成哈希表的初始化  2.完成哈希表的扩容
    if ((tab = table) == null || (n = tab.length) == 0)
        n = (tab = resize()).length;
//当目标索引未存储元素时,将当前元素存储到目标索引位置
    if ((p = tab[i = (n - 1) & hash]) == null)
        tab[i] = newNode(hash, key, value, null);
//哈希表已经初始化并且算出的数据下标已经有元素了
    else {
        Node<K,V> e; K k;
//若索引下标对应的元素key值恰好与当前元素key值相等且不为空,
//将value替换为当前元素的value
        if (p.hash == hash &&
            ((k = p.key) == key || (key != null && key.equals(k))))
            e = p;
//此时索引对应的链表已经树化了,采用红黑树方式将当前节点添加到树中
        else if (p instanceof TreeNode)
            e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
//以链表方式将当前节点添加到链表末尾
        else {
            for (int binCount = 0; ; ++binCount) { //binCount当前链表的长度
                if ((e = p.next) == null) {
                    p.next = newNode(hash, key, value, null);
                    if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                        //尝试将链表树化
                        treeifyBin(tab, hash);
                    break;
                }
                if (e.hash == hash &&
                    ((k = e.key) == key || (key != null && key.equals(k))))
                    break;
                p = e;
            }
        }
        if (e != null) { // existing mapping for key
            V oldValue = e.value;
            if (!onlyIfAbsent || oldValue == null)
                e.value = value;
            afterNodeAccess(e);
            return oldValue;
        }
    }
    ++modCount;
//扩容策略
//此时添加了新节点
    if (++size > threshold)
        //扩容
        resize();
    afterNodeInsertion(evict);
    return null;
}

为何HashMap中JDK1.8要引入红黑树?

当链表长度过长时,会将哈希表查找的时间复杂度退化为O(n),树化会保证即便在哈希冲突严重时,查找的时间复杂度也为O(logn)

当红黑树结点个数在扩容或者删除元素时减少为6以下,在下次resize()过程中会将红黑树退化为链表,节省空间