Java HashMap | 全解自源码及代码实验 | 无知的我学习日记（图文排版无水印）

无知的我终于深入接触到了HashMap。。。。

如果有遇到有任何无法进展问题或者疑惑的地方，应该在讨论区留言 或者 其他途径以寻求及时的帮助，以加快学习效率 或者 培养独立解决问题的能力、扫清盲点、补充细节

目录

• HashMap
• • HashMap-机制及特点
  • HashMap-通过扩容缩减链表的长度
  • HashMap-解决上一个缺陷的办法是红黑树化
  • HashMap-回答面试题
  • HashMap-树退化链表-树元素个数
  • HashMap-树退化链表-remove 树节点
  • HashMap-索引计算
  • HashMap-二次哈希的作用
  • HashMap-put 与 扩容
  • HashMap-负载(加载)因子为何是0.75f
  • HashMap-并发丢数据
  • HashMap-扩容死链
  • HashMap-key 的设计
  • HashMap-String 对象的 hashCode() 设计

HashMap

历程

• 1.7 数组 + 链表
• 1.8 数组 + （链表 | 红黑树）

HashMap-机制及特点

存储机制

1. 传入“a”（key值）
2. 根据“a”调用其hashCode()=>得到原始hash
3. 根据原始hash调用其hash()=>得到二次hash
4. 计算 二次hash % 16（数组容量）=>得到桶下标
5. 调用put()=>将“a”存储在了桶下标索引位置数组
6. 如下图

好处就是 能够实现快速查找。这是因为“a”与存储到的数组位置一 一对应

缺陷就是 不同的值可以储存到数组的相同的位置。这些值以链表的方式存储。如下图

解决上面所说的缺陷的两种思路

1. 缩减链表的长度
2. 使用红黑树的数据结构存储这些值

HashMap-通过扩容缩减链表的长度

做法

让元素个数到达数组容量的3/4。如下图

扩容缩减链表的长度 原理是什么？

这是因为当数组扩容的时候，所有的元素会根据新的数组容量计算桶下标。如下图

缺陷是 如果值得原始hash一致，那么它们不会随着扩容而改变原来的桶下标。原因显而易见

HashMap-解决上一个缺陷的办法是红黑树化

如果当前数组容量没有 >= 64

• 使得它们的数量 > 红黑树化的 8 阈值 -> 数组自动扩容到64。这就意味着可能再次通过数组扩容而缩短链表的长度了。
• 如下图

如果当前数组容量 >= 64

• 使得它们的数量 > 红黑树化的 8 阈值 -> 链表红黑树化。
• 如下图

可知，红黑树是什么

• 每一个父结点的值比它的左孩子的大
• 每一个父结点的值比它的右孩子的小

红黑树能否提升查找效率？

根据上图，可以知道，如果要查找“8”，那么只需要比较3次。时间复杂度是O(log2^n) //原本的时间复杂度是O(n)

**红黑树中10、11的位置是怎么回事？**如下图

这是因为红黑树是按照字符串排序的

HashMap-回答面试题

底层数据结构，1.7和1.8有何不同？

何时会树化？

为什么不一开始树化？

1. 在性能上，如果把短的链表转化为红黑树，查找性能不会提高
2. 在内存占用上，红黑树的占用更高。这是因为其底层数据结构是treeNode实现的，而链表是node实现的

为什么要使用红黑树？

• 红黑树用来避免 DoS 攻击，防止链表超长时性能下降，树化应当是偶然情况，是保底策略
• hash 表的查找，更新的时间复杂度是 O ( 1 ) O(1) O(1)，而红黑树的查找，更新的时间复杂度是 O ( l o g 2 ⁡ n ) O(log_2⁡n ) O(log2​⁡n)，TreeNode 占用空间也比普通 Node 的大， 如非必要，尽量还是使用链表

树化阈值为什么是“8”？

• 经过代码实验可以知道，不可能出现链表个数超过8的情况

那么链表个数超过8的情况是什么？

• 当受到恶意DOSS攻击时

=>hash 值如果足够随机，则在 hash 表内按泊松分布，在负载因子 0.75 的情况下，长度超过 8 的链表出现概率是 0.00000006，树化阈值选择 8 就是为了让树化几率足够小

HashMap-树退化链表-树元素个数

在扩容时，如果树元素个数 <= 6 则会退化为链表

as 扩容前

扩容后

不会因为扩容而退化的情况

HashMap-树退化链表-remove 树节点

remove 树节点前，若 root、root.left、root.right、root.left.left 有一个为 null ，移除之后会退化为链表。

as 移除前（此时左孙子都没了）

移除“7”后

as2

移除“8”、“6”、“3”后

HashMap-索引计算

计算步骤

• 首先，计算对象的 hashCode()
• 再进行调用 HashMap 的 hash() 方法进行二次哈希
  • 二次 hash() 是为了综合高位数据，让哈希分布更为均匀
• 最后 & (capacity – 1) || % capacity 得到索引。//“& ”的效率更高。这是因为“%”类似于除法运算，耗费的时钟周期更多

引出问题-在最后一步骤使用 & (capacity – 1 =>得到索引 的前提

• capacity 是 2 的 n 次幂

数组容量为何是 2 的 n 次幂时更好

1. 计算索引时，效率更高：如果是 2 的 n 次幂可以使用位与运算代替取模
2. 扩容时，重新计算索引效率更高：
   1. 如果hash & oldCap == 0 的元素留在原来位置
   2. 否则新位置 = 旧位置 + oldCap //移动元素是一次性地，而不是一个个地不使用

数组容量是 2 的 n 次幂时的其他注意事项

• 如果 hash 表的容量不是 2 的 n 次幂，则不必二次 hash。这是因为二次 hash 是为了配合 容量是 2 的 n 次幂 这一设计前提，
• 容量是 2 的 n 次幂 这一设计计算索引效率更好，但 hash 的分散性就不好，需要二次 hash 来作为补偿，没有采用这一设计的典型例子是 Hashtable

@hash 的分散性不好 证明如下

• 当值都是偶数时，那么奇数索引不会存放有值，都在偶数索引中，解决办法是用容量为质数的数组，此时也可以不用二次哈希

HashMap-二次哈希的作用

1.8 二次哈希源码

1.7 二次哈希源码

模拟 1.8 二次哈希源码

模拟 1.7 二次哈希源码

通过代码实验，可以知道二次哈希的作用是

使得链表的长度更短（或者说元素分布更均匀）

HashMap-put 与 扩容

put 流程

1. HashMap 是懒惰创建数组的，首次使用才创建数组
2. 计算索引（桶下标）
3. 如果桶下标还没人占用，创建 Node 占位返回
4. 如果桶下标已经有人占用
   1. 已经是 TreeNode 走红黑树的添加或更新逻辑
   2. 是普通 Node，走链表的添加或更新逻辑，如果链表长度超过树化阈值，走树化逻辑
5. 返回前检查容量是否超过阈值，一旦超过进行扩容

1.7 与 1.8 的区别

1. 链表插入节点时，1.7 是头插法，1.8 是尾插法
2. 1.7 是大于等于阈值且没有空位时才扩容，而 1.8 是大于阈值就扩容
3. 1.8 在扩容计算 Node 索引时，会优化

HashMap-负载(加载)因子为何是0.75f

1. 在空间占用与查询时间之间取得较好的权衡
2. 大于这个值，空间节省了，但链表就会比较长影响性能
3. 小于这个值，冲突减少了，但扩容就会更频繁，空间占用也更多

HashMap-并发丢数据

创建两个线程，打算分别往“1”处存入数据

package day01.map;

import java.util.HashMap;

public class HashMapMissData {
    public static void main(String[] args) throws InterruptedException {

        HashMap<String, Object> map = new HashMap<>();
        Thread t1 = new Thread(() -> {
            map.put("a", new Object()); // 97  => 1
        }, "t1");

        Thread t2 = new Thread(() -> {
            map.put("1", new Object()); // 49 => 1
        }, "t2");

        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(map);
    }
}

设置断点，打算让“t2”线程先存入

让“t2”线程存入

再让“t1”线程存入

可以知道，“t1”线程存入的数据覆盖了之前“t2”线程存入的数据

HashMap-扩容死链

扩容死链（1.7 会存在）

1.7 源码如下：

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;
        }
    }
}

• e 和 next 都是局部变量，用来指向当前节点和下一个节点
• 线程1（绿色）的临时变量 e 和 next 刚引用了这俩节点，还未来得及移动节点，发生了线程切换，由线程2（蓝色）完成扩容和迁移

• 线程2 扩容完成，由于头插法，链表顺序颠倒。但线程1 的临时变量 e 和 next 还引用了这俩节点，还要再来一遍迁移

• 第一次循环
  • 循环接着线程切换前运行，注意此时 e 指向的是节点 a，next 指向的是节点 b
  • e 头插 a 节点，注意图中画了两份 a 节点，但事实上只有一个（为了不让箭头特别乱画了两份）
  • 当循环结束是 e 会指向 next 也就是 b 节点

• 第二次循环
  • next 指向了节点 a
  • e 头插节点 b
  • 当循环结束时，e 指向 next 也就是节点 a

• 第三次循环
  • next 指向了 null
  • e 头插节点 a，a 的 next 指向了 b（之前 a.next 一直是 null），b 的 next 指向 a，死链已成
  • 当循环结束时，e 指向 next 也就是 null，因此第四次循环时会正常退出

数据错乱（1.7，1.8 都会存在）
略

HashMap-key 的设计

key 的设计要求

1. HashMap 的 key 可以为 null，但 Map 的其他实现则不然（如treeMap、hashTable）
2. 作为 key 的对象，必须实现 hashCode（为了更好的分布性而提高查找性能） 和 equals（如果key不同，用于比较是否相同的对象），并且 key 的内容不能修改（不可变）
3. key 的 hashCode 应该有良好的散列性

如果 key 可变，例如修改了 age 会导致再次查询时查询不到

public class HashMapMutableKey {
    public static void main(String[] args) {
        HashMap<Student, Object> map = new HashMap<>();
        Student stu = new Student("张三", 18);
        map.put(stu, new Object());

        System.out.println(map.get(stu));

        stu.age = 19;
        System.out.println(map.get(stu));
    }

    static class Student {
        String name;
        int age;

        public Student(String name, int age) {
            this.name = name;
            this.age = age;
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }

        public int getAge() {
            return age;
        }

        public void setAge(int age) {
            this.age = age;
        }

        @Override
        public boolean equals(Object o) {
            if (this == o) return true;
            if (o == null || getClass() != o.getClass()) return false;
            Student student = (Student) o;
            return age == student.age && Objects.equals(name, student.name);
        }

        @Override
        public int hashCode() {
            return Objects.hash(name, age);
        }
    }
}

这是因为在查找时，需要根据key值计算索引来查找，但是修改key值后，会使得查找索引也发生改变

HashMap-String 对象的 hashCode() 设计

目标是达到较为均匀的散列效果，每个字符串的 hashCode 足够独特

//字符串中的每个字符都可以通过查询码表表现为一个数字，称为 S i S_i Si​，其中 i 的范围是 0 ~ n - 1

• 不是直接相加这些数字，而是使用散列公式错开这些字符： S 0 ∗ 3 1 ( n − 1 ) + S 1 ∗ 3 1 ( n − 2 ) + … S i ∗ 3 1 ( n − 1 − i ) + … S ( n − 1 ) ∗ 3 1 0 S_0∗31^{(n-1)}+ S_1∗31^{(n-2)}+ … S_i ∗ 31^{(n-1-i)}+ …S_{(n-1)}∗31^0 S0​∗31(n−1)+S1​∗31(n−2)+…Si​∗31(n−1−i)+…S(n−1)​∗310

为什么每次乘于 31 而不是其他数字

• 31 代入公式有较好的散列特性
• 31 * h 可以被优化为
  • 即 ∗h -h $
  • 即 2 5 ∗ h − h 2^5 ∗h -h 25∗h−h
  • 即 h ≪ 5 − h h≪5 -h h≪5−h

证明 31 代入公式有较好的散列特性？

对比乘于 11 的效果

对比乘于 41 的效果

• 乘于 41 的分布性更好
• 但是计算性能更低，不能移位运算。这是因为其相邻的数字不是 2的n次幂
• =>还是乘于 31 更好

涉及资料

• 满老师