在Java后端开发的面试中，hashmap十大面试题几乎是绕不开的“拦路虎”。作为Java集合框架中最核心的数据结构之一，HashMap不仅承载着日常开发中大量的数据缓存与映射任务，更是考察候选人对哈希算法、内存管理、并发编程理解程度的试金石。本文将为您逐一拆解这十道经典题目，并提供超越标准答案的深度解析。
HashMap的设计精妙之处在于它平衡了时间复杂度与空间复杂度。理想情况下，通过哈希函数将键映射到数组索引，可以实现O(1)的查找效率。然而，现实中的哈希冲突、负载因子调整以及JDK版本迭代带来的底层结构变化（如红黑树的引入），使得HashMap成为了一个极其复杂的系统。掌握这些知识点，不仅有助于通过面试，更能提升您在实际开发中处理高性能场景的能力。
⚡ 核心提示： 本文内容基于JDK 1.8及更高版本，结合最新大厂面试趋势，旨在提供最具实战价值的hashmap十大面试题攻略。
以下整理了面试中出现频率最高、考察深度最深的十道题目，建议收藏反复研读。
在JDK 1.7中，HashMap由“数组+链表”组成；而在JDK 1.8中，引入了红黑树，结构变为“数组+链表+红黑树”。当链表长度超过8且数组长度超过64时，链表会转换为红黑树，以提高查询效率。
HashMap底层使用位运算(&)来计算索引，即 (n-1) & hash。只有当n为2的幂次方时，n-1的二进制位才全为1，这样能保证哈希值均匀分布，减少哈希冲突，提高存储效率。
主要采用“链地址法”。当不同键映射到同一索引时，它们会以链表形式存储。如果链表过长，JDK 1.8会将其转换为红黑树，将时间复杂度从O(n)降低到O(log n)。
负载因子（loadFactor）衡量HashMap的满度。默认值为0.75，这是时间效率和空间效率的一个折中点。当元素数量超过 容量 负载因子 时，HashMap会进行扩容。
扩容时，新容量为原容量的2倍。JDK 1.8优化了扩容过程，通过判断原索引位置上的节点在扩容后是留在原位置还是移动到“原索引+旧容量”的位置，避免了重新计算哈希值，提高了扩容效率。
HashMap不是线程安全的。在多线程环境下，并发put可能导致数据覆盖、死循环（JDK 1.7）或数据不一致等问题。如果需要线程安全，应使用ConcurrentHashMap。
必须重写equals()和hashCode()方法。hashCode()用于确定存储位置，equals()用于判断键是否相同。如果只重写其中一个，会导致HashMap无法正确检索数据。
HashMap允许null键和null值，非线程安全，性能较高；Hashtable不允许null，所有方法同步，线程安全但性能较低，是遗留类，建议用ConcurrentHashMap替代。
是的。HashMap的迭代器是fail-fast的。如果在迭代过程中检测到结构被修改（除了通过迭代器自身的remove方法），会抛出ConcurrentModificationException。
String是不可变类，其hashCode在创建时缓存，使得获取哈希值非常快。此外，String的equals()比较的是内容，确保了键的唯一性，非常适合做Key。
put方法是HashMap的核心。其基本流程如下：
// 简化版put逻辑伪代码
public V put(K key, V value) {
return putVal(hash(key), key, value, false, true);
}
final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
// 1. 初始化或扩容
// 2. 计算索引
// 3. 处理冲突 (链表或树)
// 4. 计数与扩容检查
}get方法相对简单，主要目的是根据key找到对应的value：
由于红黑树的引入，get操作在最坏情况下的时间复杂度从O(n)优化到了O(log n)。
JDK 1.8的扩容算法是一个亮点。它不需要重新计算哈希，而是利用扩容后容量是原来的2倍这一特性：
这种设计极大地提高了扩容效率，避免了大量的哈希重算。
在多线程环境下使用HashMap会导致严重问题，主要包括以下几点：
两个线程同时put不同的key，但计算出的索引相同，且未处理冲突逻辑，可能导致后写入的线程覆盖先写入的线程的数据。
在JDK 1.7中，多线程扩容时，由于链表反转操作的非原子性，可能导致链表形成环，造成死循环，CPU占用率飙升。
虽然JDK 1.8解决了死循环问题，但仍存在数据覆盖或丢失的风险。例如，一个线程正在扩容，另一个线程正在读取，可能读到null或旧数据。
| 方案 | 特点 | 适用场景 |
|---|---|---|
| Hashtable | 所有方法synchronized，性能差 | 老旧项目兼容，不推荐新项目使用 |
| Collections.synchronizedMap | 包装类，整个Map加锁 | 对性能要求不高，需快速解决线程安全 |
| ConcurrentHashMap | 分段锁（JDK 1.7）/ CAS + synchronized（JDK 1.8），性能高 | 高并发环境，首选方案 |
除了核心的hashmap十大面试题，面试官往往还会结合以下周边知识点进行追问，以考察候选人的知识广度。
31是一个奇素数，如果乘以偶数，乘法溢出会导致信息丢失。选择31是因为JVM可以将其优化为位运算 (i << 5) - i，提高计算效率。同时，31在哈希分布上表现良好，能有效减少冲突。
HashMap基于哈希表实现，查找、插入、删除时间复杂度为O(1)，但不保证顺序；TreeMap基于红黑树实现，查找、插入、删除时间复杂度为O(log n)，且按键的自然顺序或自定义比较器排序。
常见方式有：
在性能上，如果使用keySet，建议直接缓存entrySet，避免重复调用key的hashCode和equals。
JDK 1.7及之前的版本主要缺陷包括：1. 扩容时链表反转导致死循环；2. 只有链表，长链表查询效率低；3. 哈希算法相对简单，易受攻击。
A: 允许。HashMap允许一个null键和多个null值。null键总是存储在数组的第一个位置。
A: 因为HashMap依赖hashCode()来确定存储位置。如果两个对象equals()为true，但hashCode()不同，它们会被存储在不同的桶中，导致无法通过get()找到之前put进去的对象，破坏了Map的契约。
A: 默认初始容量是16。如果在构造时指定了容量，HashMap会将其调整为大于该值的最小的2的幂次方。