深入剖析JDK1.8 HashMap的hash的不同实现

Asthenian
215 阅读12分钟

本文将详细分析JDK1.8版本中HashMap的put流程、树化与反树化阈值，以及JDK1.7与JDK1.8在hashCode实现和数组索引映射操作上的差异。通过模拟面试官的“拷问”方式，我们将对每个问题进行2~3层的深入剖析，确保内容详尽且逻辑清晰。

一、JDK1.8 HashMap的put流程

问题：请详细讲解JDK1.8中HashMap的put流程，包含所有关键步骤和边界条件。

回答：

HashMap的put方法用于将键值对插入或更新到哈希表中。以下是put的详细流程，基于JDK1.8源码（put(K key, V value)方法最终调用putVal方法）：

  1. 初始化检查：

    • 如果HashMap的底层数组table为null或长度为0，调用resize()方法初始化数组。
    • 初始容量由构造方法指定，默认值为16，负载因子默认0.75。

  2. 计算哈希值并定位索引：

    • 对键key调用hash()方法，计算哈希值：hash = (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16)。
    • 使用(n - 1) & hash计算数组索引i，其中n是数组长度。
    • 这一步确保哈希值均匀分布，减少冲突。

  3. 处理桶内情况：

    • 情况1：桶为空：

      • 如果table[i]为null，直接创建一个新节点Node并放入该位置。

    • 情况2：桶内为红黑树节点：

      • 如果table[i]是TreeNode类型（红黑树节点），调用putTreeVal方法将键值对插入红黑树。
      • 插入后检查树是否平衡，可能触发旋转或重新着色。

    • 情况3：桶内为链表：

      • 遍历链表，检查是否有键相同的节点：

        • 如果找到相同键（key.equals(existingKey)），更新节点的值。
        • 如果未找到相同键，将新节点插入链表尾部（尾插法）。

      • 插入后检查链表长度是否达到树化阈值（默认8），若达到且数组长度≥64，调用treeifyBin将链表转为红黑树。

  4. 更新size并检查扩容：

    • 插入后，HashMap的size加1。
    • 如果size超过阈值（threshold = capacity * loadFactor），调用resize()扩容。
    • 扩容将数组长度翻倍，重新分配所有节点（rehash）。

  5. 返回旧值：

    • 如果更新了已有键，返回旧值；否则返回null。

深入分析（第1层）：为什么需要hash方法的高低位异或操作？

  • JDK1.8的hash方法通过h ^ (h >>> 16)将高16位与低16位异或，目的是让哈希值更均匀。
  • 原因：数组长度n通常较小（如16），(n - 1) & hash只使用哈希值的低位，高位信息可能丢失。异或操作让高位信息参与索引计算，减少冲突。
  • 例如：两个键的低位相同但高位不同，异或后索引可能不同，避免集中在一个桶。

深入分析（第2层）：尾插法与头插法的区别？

  • JDK1.8使用尾插法（新节点加到链表末尾），而JDK1.7使用头插法（新节点加到链表头部）。

  • 尾插法的好处：

    • 避免扩容时多线程环境下链表形成环（JDK1.7头插法在并发resize时可能导致环）。
    • 插入顺序更直观，符合逻辑。

  • 缺点：尾插法需要遍历链表，性能略低于头插法，但安全性更高。

深入分析（第3层）：resize的细节如何影响put性能？

  • resize涉及数组扩容和节点重新分配：

    • 新数组长度为旧数组的2倍。
    • 每个节点根据新数组长度重新计算索引，可能分配到原索引或原索引 + 旧数组长度。

  • 性能影响：

    • 扩容时需要遍历所有节点并重新计算哈希，时间复杂度为O(n)。
    • 红黑树节点在扩容后可能反树化为链表（如果桶内节点数减少）。

  • 优化：JDK1.8在扩容时利用hash & oldCap判断节点位置，减少计算开销。

面试官拷问：

  • Q1：如果key为null，put流程有什么不同？

    • 答：HashMap允许key为null，其哈希值为0，固定映射到索引0的桶。流程与其他键相同，但需特别检查key == null（而非equals）。

  • Q2：多线程环境下put可能出现什么问题？

    • 答：JDK1.8的HashMap非线程安全，多线程put可能导致：

      • 节点丢失：并发插入同一桶可能覆盖节点。
      • 死循环：扩容时多线程操作可能导致链表异常。
      • 推荐使用ConcurrentHashMap或加锁。

  • Q3：红黑树插入的时间复杂度是多少？

    • 答：红黑树插入时间复杂度为O(log n)，其中n是树中节点数。相比链表的O(n)，在冲突严重时性能更优。

二、树化与反树化阈值

问题：讲解JDK1.8中HashMap的树化与反树化阈值，包括原因和影响。

回答：

JDK1.8引入红黑树优化长链表的查询性能，涉及树化（链表转为红黑树）和反树化（红黑树转为链表）两个过程，依赖以下阈值：

  • 树化阈值（TREEIFY_THRESHOLD） ：

    • 默认值：8。
    • 当某个桶内链表节点数达到8且数组长度≥64时，调用treeifyBin将链表转为红黑树。

  • 反树化阈值（UNTREEIFY_THRESHOLD） ：

    • 默认值：6。
    • 当红黑树节点数减少到6或以下（通常在remove或resize时），调用untreeify将红黑树转为链表。

  • 最小树化数组长度（MIN_TREEIFY_CAPACITY） ：

    • 默认值：64。
    • 即使链表长度达到8，如果数组长度<64，不会树化，而是触发扩容。

深入分析（第1层）：为什么选择8和6作为阈值？

  • 泊松分布依据：

    • 假设哈希函数均匀分布，桶内节点数符合泊松分布。Sun工程师通过数学建模发现，链表长度达到8的概率极低（约百万分之一）。
    • 选择8作为树化阈值，既避免频繁树化（开销较大），又能在链表过长时优化性能。

  • 6作为反树化阈值的缓冲：

    • 6比8小，防止频繁在树和链表间切换（例如反复插入/删除导致节点数在7~8间波动）。
    • 提供“滞后效应”，提高稳定性。

深入分析（第2层）：为什么需要最小树化数组长度64？

  • 避免过早树化：

    • 如果数组长度小（如16），桶少，冲突概率高，链表容易变长。此时树化不如扩容更有效（扩容减少冲突）。
    • 64是经验值，平衡了树化开销和扩容成本。

  • 性能权衡：

    • 树化涉及节点类型转换（Node到TreeNode）和平衡调整，开销较高。
    • 扩容通过增加桶数降低冲突，适合早期优化。

深入分析（第3层）：树化与反树化的性能影响？

  • 树化性能：

    • 树化时间复杂度为O(n log n)，n为链表节点数（需构建红黑树）。
    • 查询性能从链表的O(n)提升到红黑树的O(log n)，适合冲突严重的场景。

  • 反树化性能：

    • 反树化时间复杂度为O(n)，直接将树节点转为链表。
    • 红黑树维护成本高（旋转、着色），节点数少时链表更高效。

  • 实际场景：

    • 树化在高冲突场景（如哈希函数不佳）显著提升性能。
    • 反树化在节点减少后降低维护开销。

面试官拷问：

  • Q1：如果哈希函数极差，树化阈值8是否合理？

    • 答：极差的哈希函数可能导致大量键映射到少数桶，链表频繁达到8，树化频繁发生。阈值8基于均匀分布假设，可能需调整（如降低阈值）或优化哈希函数。

  • Q2：为什么不直接用红黑树替代链表？

    • 答：红黑树节点（TreeNode）占用内存比普通节点（Node）大，维护成本高（旋转、平衡）。链表在节点数少时更简单高效，综合性能更优。

  • Q3：反树化阈值6和树化阈值8的差值2有什么意义？

    • 答：差值2提供缓冲，避免节点数在7附近反复触发树化/反树化，减少性能抖动。

三、JDK1.8与JDK1.7中hashCode的实现差异

问题：对比JDK1.7和JDK1.8中HashMap的hashCode实现差异，并分析原因。

回答：

在HashMap中，hashCode用于生成键的哈希值，影响键的分布。JDK1.7和JDK1.8的hash方法（用于处理key.hashCode()）存在显著差异：

  • JDK1.7的hash方法：

    final int hash(Object k) {
    int h = 0;
    if (k != null) {
        h = k.hashCode();
        h ^= (h >>> 20) ^ (h >>> 12);
        h ^= (h >>> 7) ^ (h >>> 4);
    }
    return h;
}
    • 多次位移和异或操作，扰动原始hashCode。
    • 复杂计算，涉及4次位移和3次异或。

  • JDK1.8的hash方法：

    static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
    • 仅一次右移16位和一次异或，简单高效。
    • 将高16位与低16位异或，增强均匀性。

深入分析（第1层）：为什么JDK1.8简化hash方法？

  • 性能优化：

    • JDK1.7的hash方法计算复杂，多次位运算增加开销。
    • JDK1.8通过一次高低位异或，减少计算量，同时保持较好的分布均匀性。

  • 高低位混合：

    • 数组索引计算依赖低位（(n - 1) & hash），JDK1.7的多次扰动试图让低位更随机，但效果有限且开销大。
    • JDK1.8的h ^ (h >>> 16)直接让高位参与低位计算，效果类似但更高效。

深入分析（第2层）：hash方法变化对冲突率的影响？

  • 冲突率：

    • JDK1.7的复杂扰动在理论上可能略微降低冲突率，但实际场景中差异不大（因hashCode质量更关键）。
    • JDK1.8的简单扰动在大多数场景下冲突率与JDK1.7接近，但在极端情况下（如hashCode高位差异小）可能略逊。

  • 红黑树弥补不足：

    • JDK1.8引入红黑树，即使哈希函数不佳，长链表会树化，查询性能仍可保证。
    • 因此，JDK1.8更依赖红黑树而非复杂的hash方法来处理冲突。

深入分析（第3层）：hash方法对多线程场景的影响？

  • 计算开销：

    • JDK1.8的hash方法更快，减少多线程环境下竞争时间。
    • 但HashMap本身非线程安全，hash方法的优化对并发性能影响有限。

  • 一致性：

    • 两版本的hash方法都确保相同键的哈希值一致，迁移时不影响已有数据。

面试官拷问：

  • Q1：如果key的hashCode实现很差，两种hash方法表现如何？

    • 答：差的hashCode（如常量或低位变化少）会导致高冲突率。JDK1.7的多次扰动可能略微改善分布，但效果有限；JDK1.8依赖红黑树，长期性能更稳定。

  • Q2：为什么JDK1.8不完全依赖key.hashCode？

    • 答：key.hashCode()可能质量不佳（如字符串哈希值高位变化小），直接使用可能导致冲突集中。扰动增加随机性，降低冲突概率。

  • Q3：hash方法的性能优化有多大实际意义？

    • 答：在高频put场景，JDK1.8的hash方法减少位运算，性能提升明显（约数倍）。但整体put性能还受链表/红黑树操作影响，hash优化只是部分提升。

四、JDK1.7与JDK1.8中将hash值映射到数组索引的差异

问题：对比JDK1.7和JDK1.8中HashMap将hash值映射到数组索引的操作差异，并分析原因。

回答：

将哈希值映射到数组索引是HashMap的核心操作，决定键值对存储的桶位置。JDK1.7和JDK1.8在此操作上的实现如下：

  • JDK1.7的索引映射：

    int index = hash & (table.length - 1);
    • 直接使用hash（经过复杂扰动）与table.length - 1进行位与运算。
    • 要求table.length为2的幂，确保(length - 1)的低位全为1，映射均匀。

  • JDK1.8的索引映射：

    int i = (n - 1) & hash;
    • 形式上与JDK1.7相同，使用hash（经过高低位异或）与n - 1（n为数组长度）位与。
    • 核心差异在于hash的计算方式（见上一节）。

深入分析（第1层）：两版本索引映射的核心差异？

  • hash值的质量：

    • JDK1.7的hash经过多次扰动，低位随机性稍强，但计算开销大。
    • JDK1.8的hash通过高低位异或，计算更快，低位随机性略逊但仍有效。

  • 实际效果：

    • 索引映射公式相同，差异源于hash的生成方式。
    • JDK1.8的映射依赖红黑树优化冲突，降低对hash均匀性的要求。

深入分析（第2层）：为什么坚持使用(n - 1) & hash？

  • 2的幂长度：

    • HashMap的数组长度始终为2的幂（如16、32），n - 1的二进制低位全为1（如15为1111）。
    • 位与运算等价于取模（hash % n），但位运算更快。

  • 均匀分布：

    • (n - 1) & hash确保哈希值低位均匀映射到0到n-1的索引。
    • 如果n不是2的幂，位与运算可能导致索引分布不均。

深入分析（第3层）：索引映射对扩容的影响？

  • 扩容后重新映射：

    • 扩容时数组长度翻倍（如16→32），n - 1的位掩码变长（如1111→11111）。
    • JDK1.8优化了rehash逻辑：节点要么保留原索引，要么移到原索引 + 旧长度，通过hash & oldCap判断，减少计算。

  • JDK1.7的不足：

    • JDK1.7扩容时需对每个节点重新计算hash & (newLength - 1)，开销较大。
    • JDK1.8的优化使扩容更快，尤其在大规模数据时。

面试官拷问：

  • Q1：如果数组长度不是2的幂，会怎样？

    • 答：(n - 1) & hash依赖n为2的幂。若n不是2的幂（如10，n - 1为9，1001），位与运算会导致索引分布不均，某些桶永远为空，增加冲突。

  • Q2：JDK1.8的索引映射优化如何提升性能？

    • 答：JDK1.8通过简化hash计算和优化扩容时的rehash逻辑，减少位运算和索引重算次数，整体性能提升约10%-20%（视数据规模）。

  • Q3：位与运算与取模运算的性能差异？

    • 答：位与运算（&）是单指令操作，纳秒级；取模（%）涉及除法，微秒级。位与运算性能远高于取模，适合高频索引计算。

总结

本文通过模拟面试官的“拷问”，深入剖析了JDK1.8中HashMap的put流程、树化与反树化阈值，以及JDK1.7与JDK1.8在hashCode实现和索引映射上的差异。每个问题都进行了2~3层的分析，覆盖了设计原理、性能影响和边界条件。总结关键点如下：

  • put流程：初始化、哈希计算、桶处理、扩容，优化了冲突和并发安全。
  • 树化/反树化：阈值8和6平衡了性能和开销，数组长度64避免过早树化。
  • hashCode差异：JDK1.8简化扰动，依赖红黑树优化冲突。
  • 索引映射：两版本公式相同，JDK1.8通过hash和rehash优化提升性能。

希望本文能帮助读者深入理解HashMap的实现细节，并在面试中从容应对相关问题！

avatar
文章
阅读
粉丝