HashMap从入门到源码：Java7/8/21区别+面试陷阱+高频追问合集

文章目录

- 一、开篇：图书馆管理员的烦恼
- [二、Java 7：那个时代的"头铁"设计](#二、Java 7：那个时代的"头铁"设计)
- [三、Java 8：老树开新花，红黑树登场](#三、Java 8：老树开新花，红黑树登场)
- [四、Java 21：新时代的"微整形"](#四、Java 21：新时代的"微整形")
- 五、面试陷阱：那些让你挂掉的细节
- 六、高频追问：面试官的连环炮
- - Q1：HashMap能存null键吗？原理是啥？
  - Q2：红黑树退化成链表的条件？
  - Q3：为啥不用AVL树用红黑树？
  - Q4：HashMap初始化时指定容量，实际容量就是指定的吗？
  - [Q5：Java 8的stream操作对HashMap性能有影响吗？](#Q5：Java 8的stream操作对HashMap性能有影响吗？)
- 七、源码里的魔鬼细节
- 八、实战建议：别在简历上给自己挖坑
- 九、总结

无意间发现了一个巨牛巨牛巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01

一、开篇：图书馆管理员的烦恼

想象一下，你是个图书馆管理员，手里有1000本书，读者来借书时你得一排排扫过去找，这得多崩溃？HashMap就是来解决这问题的------它像个智能书架，你告诉它书名（key），它秒秒钟给你定位到第几排第几格（value）。但这么个看似简单的东西，Java版本迭代里却藏了无数坑，面试时面试官眼神一闪："说说HashMap在Java 7和8的区别？" 你要是只答个"加了红黑树"，那基本就凉了半截。

今天咱们不整那些虚的，从源码层面把这玩意儿扒个底朝天，顺带把Java 21的新变化也给你整明白。

二、Java 7：那个时代的"头铁"设计

Java 7的HashMap，结构简单得让人心疼：数组+链表，没了。

那时候处理哈希冲突用的是头插法。啥意思？就是新来的元素直接插到链表头部，老元素被挤到后面。代码大概长这样：

java 复制代码

// Java 7 头插法简化逻辑
void addEntry(int hash, K key, V value, int bucketIndex e = table[bucketIndex];
table[bucket<>(hash, key, value, e); // 新节点指向旧链表
}

听着挺高效？插入是O(1)，不用遍历到链表尾部。但这玩意儿有个致命bug------并发环境下的死循环。两个线程同时扩容的时候，因为头插法会改变链表顺序，最后可能形成一个环，你get()的时候直接死循环，CPU飙到100%。这也是为什么面试时你说"HashMap是线程不安全的"，面试官会让你展开讲讲，看你知道不知道这个死循环的梗。

而且Java 7的哈希计算也糙，直接拿key的hashCode高位异或低位，扰动次数少，哈希碰撞概率高。数据量一大，链表长得跟贪吃蛇似的，查询直接退化成O(n)。

三、Java 8：老树开新花，红黑树登场

Java 8算是HashMap的翻身仗。最大的改动就仨字：红黑树。

但别急着背概念，咱先想个问题：链表太长的时候，查询慢得跟蜗牛爬似的，能不能用二叉搜索树加速？能，但普通二叉树会退化成链表。于是Java 8祭出了红黑树------一种自平衡的二叉搜索树，保证最坏情况下查询也是O(log n)。

具体触发条件是：链表长度≥8，且数组长度≥64。为啥是8？源码里写了，根据泊松分布，hash冲突达到8的概率已经低得可怜（0.00000606），用树结构的额外开销才值得。要是数组长度不到64，优先扩容而不是树化，毕竟扩容比树化便宜多了。

还有个大改动，Java 8把头插法改成了尾插法。新元素老老实实排到链表尾巴上，这样并发扩容的时候不会再形成环，虽然还是线程不安全（数据丢失问题还在），但至少不会死循环了。

哈希计算也优化了，把高16位和低16位异或，扰动更充分，减少碰撞。resize的逻辑也重写了，Java 7是重新算hash定位，Java 8发现扩容后元素位置要么在原位，要么在原位置+旧容量（因为容量是2的幂次方），直接省去了重新hash的开销。

java 复制代码

// Java 8 尾插法核心逻辑
final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) p; int n, i;
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 {
// 冲突了，遍历链表
for (int binCount = 0; ; ++binCount) {
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null); // 插到尾部
if (binCount >= TREEIFY_THRESHOLD - 1) // 达到8个转红黑树
treeifyBin(tab, hash);
break;
}
if (e.hash == hash && ((ek = e.key) == key || (ek != null && key.equals(ek))))
break;
p = e;
}
}
}

四、Java 21：新时代的"微整形"

到了Java 21（LTS版本），HashMap的结构没变，还是数组+链表+红黑树，但底层做了不少"微整形"。

首先是内存布局优化。Java 21对对象头（Header）和字段对齐做了调整，在64位JVM上，HashMap的Node对象内存占用更紧凑了。对于大容量的HashMap，能省出不少内存。比如你塞100万个Entry进去，Java 21可能比Java 8少用几MB内存，听起来不多，但在高并发场景下，缓存友好性提升明显。

其次是虚拟线程（Virtual Threads）兼容性。虽然HashMap本身还是非线程安全的，但Java 21的虚拟线程环境下，ThreadLocal的改动间接影响了HashMap的使用模式。以前在大量线程场景下，用ConcurrentHashMap是标配，现在虚拟线程轻量化了，有些场景下用HashMap配合其他同步手段也变得更可行（当然，并发修改还是要用ConcurrentHashMap，这点没变）。

还有性能上的暗搓搓优化。Java 21的JIT编译器对HashMap的resize和treeify操作做了更好的内联优化，特别是红黑树的旋转操作，在部分基准测试里比Java 17快了5-10%。虽然日常CRUD感知不强，但对于高频交易系统或者大数据处理，这提升就很香了。

五、面试陷阱：那些让你挂掉的细节

陷阱1：为什么容量必须是2的幂次方？

别只说"为了取模快"。真实原因是HashMap用(n-1) & hash来代替hash % n，位运算比取模快得多。但只有当n是2的幂时，n-1的二进制才是全1（比如16是10000，15是01111），这样与运算才能均匀散列。如果n=10，n-1=9（1001），那hash的某些位永远参与不了运算，冲突率飙升。

陷阱2：链表转红黑树是8，转回链表是6，为啥差2？

这叫hysteresis（滞后性）。如果都是8，那在8这个临界点来回插入删除，会频繁在链表和树之间转换，性能抖动严重。设成6，相当于有个缓冲带，树变回链表需要降到6以下，避免反复横跳。

陷阱3：为什么重写equals必须重写hashCode？

HashMap先比hash，hash一样再比equals。如果你两个对象equals为true但hashCode不同，那HashMap会认为它们在不同的桶里，get的时候永远找不到，造成内存泄漏。这个坑新手必踩。

陷阱4：resize时元素的rehash

Java 8里，元素在扩容后的位置要么在原索引，要么在原索引+旧容量。因为容量翻倍，二进制高位多了一位，hash & oldCap的结果要么是0（原位），要么是1（原位+旧容量）。所以Java 8的resize比Java 7快，不需要重新算hash。

六、高频追问：面试官的连环炮

Q1：HashMap能存null键吗？原理是啥？

能，但只能一个。null的hash被特殊处理为0，直接放在数组第0个位置。ConcurrentHashMap不让存null，是因为null有二义性（不存在vs值为null），多线程下无法区分。

Q2：红黑树退化成链表的条件？

不是长度降到8以下就退，而是resize时或者remove后检查，长度≤6才会untreeify。而且如果在remove时树太小了，可能直接untreeify；如果是resize导致节点分散，也可能退化。

Q3：为啥不用AVL树用红黑树？

AVL树严格平衡，查询快但旋转多；红黑树宽松平衡，插入删除旋转少。HashMap里插入操作更频繁，红黑树综合性能更好，实现也简单点（虽然红黑树代码已经够复杂了，300多行）。

Q4：HashMap初始化时指定容量，实际容量就是指定的吗？

不是。比如你<>(100)，实际容量会是128（最近的2的幂）。而且因为load factor默认0.75，实际上到75个元素就扩容了。如果你明确要存100个元素且不扩容，应该new<>( (int) (100 / 0.75f) + 1)`，也就是134，这样实际容量是256，足够撑到100个元素。

Q5：Java 8的stream操作对HashMap性能有影响吗？

map.entrySet().stream()其实挺快的，因为HashMap的spliterator做了优化，可以并行分割。但如果你用map.keySet().toArray()这类操作，注意Java 8之后返回的是迭代器视图，某些操作可能有轻微性能损耗。

七、源码里的魔鬼细节

看一段resize的核心代码，体会下Java 8的巧妙：

java 复制代码

[][] 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 << MAXIMUM_CAPACITY &&
oldCap >= DEFAULT_INITIAL_CAPACITY)
newThr = old< 1; // 容量和阈值都翻倍
}
// ... 省略部分代码
Node[] newTab[])new Node[newCap];
table = newTab;
if (oldTab != null) {
    for (int j = < oldCap; ++j) {
 e;
        if ((e = oldTab[j]) != null) {
            oldTab[j] = null;
            if (e.next == null)
                newTab[e.hash & (newCap - 1)] = e; // 单个元素直接放
            else if (e instanceof TreeNode)
)e).split(this, newTab, j, oldCap); // 红黑树分裂
            else { // 链表拆成两份
 loHead = null, loTail = null;
                Node hiHead = null, hiTail = null next;
                do {
                    next = e.next;
                    if ((e.hash & oldCap) == 0) { //  hash & 10000 == 0 留在低位
                        if (loTail == null)
                            loHead = e;
                        else
                            loTail.next = e;
                        loTail = e;
                    }
                    else { // 去高位
                        if (hiTail == null)
                            hiHead = e;
                        else
                            hiTail.next = e;
                        hiTail = e;
                    }
                } while ((e = next) != null);
                if (loTail != null) {
                    loTail.next = null;
                    newTab[j] = loHead; // 原位
                }
                if (hiTail != null) {
                    hiTail.next = null;
                    newTab[j + oldCap] = hiHead; // 原位+旧容量
                }
            }
        }
    }
}
return newTab;
}

看到那个(e.hash & oldCap) == 0了吗？这就是判断元素该留在原地还是去高位的关键。oldCap是旧容量，比如16（10000），hash & 16的结果只看hash的第五位（从右数），是0就在原位，是1就去j+16的位置。这种位运算的技巧，比重新hash快得多。

八、实战建议：别在简历上给自己挖坑

别在并发场景用HashMap，哪怕你是Java 21。虚拟线程环境下虽然线程开销小了，但HashMap的fast-fail机制（modCount检查）在并发修改时会抛ConcurrentModificationException，或者更糟的是丢数据。
预估容量，别让HashMap频繁resize。resize是个重操作，要新建数组，要rehash，要搬数据。如果你知道大概存多少数据，一定要在构造时指定足够大的初始容量。
自定义对象做key，务必重写hashCode和equals，并且最好是不可变对象。要是key对象后来改了内容，hashCode变了，你就再也找不到这个Entry了，这就是内存泄漏。
Java 21用var时要注意类型推断，虽然跟HashMap本身没关系，但<>()这种写法，如果后面你要用Map接口没有的方法（比如LinkedHashMap的removeEldestEntry），var推断的是HashMap具体类型，可能会限制你的灵活性。

九、总结

HashMap这玩意儿，从Java 7的简单粗暴（头插法死循环），到Java 8的华丽转身（红黑树+尾插法），再到Java 21的润物细无声（内存优化+虚拟线程适配），每一次改动都是为了应对更极端的场景和更大的数据量。

面试时别只背概念，把resize的过程、树化的触发条件、hash的计算方式这些细节整明白，再能扯两句Java 21的优化，基本上就能让面试官眼前一亮。当然，最重要的还是理解位运算在其中的妙用，以及空间换时间的核心思想。

下次面试官问HashMap，希望你不仅能答出来，还能笑着补充一句："Java 8那个尾插法改得真妙，不然现在还有人在Debug死循环呢。" 这就到位了。

无意间发现了一个巨牛巨牛巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01