HashMap（哈希映射）与 HashSet（哈希集合）：从契约到源码、扩容与故障治理

1. 简历关联点与阅读边界

HashMap（哈希映射）解决的是“按键快速定位值”，HashSet（哈希集合）解决的是“按相等语义去重”。在 WMS（仓储管理系统）库存聚合、支付回调幂等、IoT（物联网）报警窗口去重和本地缓存中，它们都很常见；但它们只负责单个 Java（编程语言）进程内的数据组织，不负责跨实例持久化、一致性或事务。

本章不重复对象相等契约和集合选型的长答案：

• 键的 equals（相等判断方法）/hashCode（哈希码方法）契约与可变键故障，见 01-Object-String与不可变设计.md。
• List（列表接口）、Set（集合接口）与 Queue（队列接口）的选型，见 03-List-Set-Queue集合体系.md。
• ConcurrentHashMap（并发哈希映射）的桶级并发与协助扩容留给后续 05 子文档；本章只划清普通 HashMap（哈希映射）的并发禁区。

2. 先分清 API（应用程序接口）契约和 OpenJDK（开放 Java 开发工具包）实现

2.1 Map（映射接口）契约、顺序边界与版本基线

Map（映射接口）约定键到值的映射关系；HashMap（哈希映射）允许一个 null（空值）键和多个 null（空值）值，不保证迭代顺序，也不是线程安全容器。键相等时后写入的值覆盖旧值；get（读取）返回 null（空值）时，可能是没有映射，也可能是显式映射了 null（空值），需要 containsKey（判断是否含键）区分。以上是面向调用者的契约。数组长度、扰动公式、树化阈值和 fail-fast（快速失败）检测则属于特定版本 OpenJDK（开放 Java 开发工具包）的实现细节。

源码核对记录。 本机已核对 JDK（Java 开发工具包）8 的 corretto-1.8.0_402 和 JDK（Java 开发工具包）21 的 openjdk-21.0.2 src.zip；本机没有 JDK（Java 开发工具包）17 的 src.zip，因此以 OpenJDK（开放 Java 开发工具包）17u 的固定 jdk-17.0.2-ga 标签源码交叉检查。JDK（Java 开发工具包）7 使用 OpenJDK（开放 Java 开发工具包）jdk7u80-b15 固定标签，避免把当前实现倒推到旧版本。

热门面试题

1. 问题（基础题）：Map（映射接口）与 HashMap（哈希映射）的边界是什么？

   • 考点：接口契约、具体实现与顺序语义。
   • 回答思路：先分开抽象接口和具体类，再说明 HashMap（哈希映射）的允许项、无序和线程边界。
   • 详细答案：Map（映射接口）定义“一个键最多关联一个当前值”的抽象关系，不要求按哈希存储；TreeMap（树映射）可以排序，LinkedHashMap（链式哈希映射）可以维护顺序。HashMap（哈希映射）是其中一个通常以哈希桶实现的类，允许一个 null（空值）键、允许 null（空值）值，并且不承诺遍历顺序。键是否相同由 equals（相等判断方法）定义，哈希只用于缩小候选桶。调用者只能依赖 API（应用程序接口）契约，不能依赖某个版本恰好先遍历到哪个桶或何时扩容。
   • 进阶追问：为什么不能把 HashMap（哈希映射）的遍历顺序写进接口协议？
   • 进阶回答：顺序会随容量、哈希分布、扩容、版本实现和插入删除历史变化；即使一次测试稳定，也不是承诺。需要插入顺序选择 LinkedHashMap（链式哈希映射），需要排序选择 TreeMap（树映射），需要跨服务稳定顺序则把排序字段写入持久化查询或消息分区协议。

2. 问题（原理题）：JDK（Java 开发工具包）7 与 JDK（Java 开发工具包）8 的 HashMap（哈希映射）最重要差异是什么？

   • 考点：链表插入方向、扩容迁移与树化。
   • 回答思路：说清 JDK（Java 开发工具包）7 的 Entry（条目节点）头插和 transfer（迁移方法），再说 JDK（Java 开发工具包）8 的尾插、Node（节点）/TreeNode（树节点）与低高位拆分。
   • 详细答案：JDK（Java 开发工具包）7u80 的桶是 Entry（条目节点）数组，冲突节点与迁移节点都通过头插接入，因此迁移会反转链表顺序；并发迁移可走到成环的历史路径。JDK（Java 开发工具包）8 改为 Node（节点）数组，普通冲突链表尾插，过长桶可变成 TreeNode（树节点）红黑树；扩容时不必对每个节点重新执行通用取模，只检查旧容量位，并保持低位组和高位组各自顺序。JDK（Java 开发工具包）17/21 的面试主路径仍与 JDK（Java 开发工具包）8 一致。
   • 进阶追问：JDK（Java 开发工具包）8 消除了 JDK（Java 开发工具包）7 的成环路径，是否就可以并发写？
   • 进阶回答：不可以。该特定头插迁移交错不再是 JDK（Java 开发工具包）8 的同一源码路径，但普通 HashMap（哈希映射）依旧没有互斥、原子性或可见性保证；两个写线程可覆盖彼此写入、丢失计数或观察到中间结构。并发容器选择与复合操作留给 ConcurrentHashMap（并发哈希映射）及其原子方法处理。

3. 问题（项目题）：支付幂等为什么不能只依赖 HashSet（哈希集合）？

   • 考点：实例边界、重启恢复与最终约束。
   • 回答思路：先给 HashSet（哈希集合）的单进程职责，再落到数据库唯一约束和状态机。
   • 详细答案：HashSet（哈希集合）适合在一个实例内快速拦截短窗口重复事件，却会在重启后清空，在多实例下各自持有不同副本，并且容量无界时还会挤占堆。支付最终幂等应把渠道事件标识组成不可变业务键，在数据库建立唯一约束；事务内仅首个插入者推进支付状态、写账务和待发送事件，冲突者读取已有结果。Redis（远程字典服务）可承担削峰或快速拒绝，但不能替代数据库唯一约束、条件更新和支付状态机。
   • 进阶追问：本地 HashSet（哈希集合）在支付链路中还有价值吗？
   • 进阶回答：有，但只能作为可丢失的性能层，例如同一实例接到短时重复回调时减少重复验签和远程查询。它必须设置最大容量和过期清理，命中与否都不能改变数据库唯一约束和状态机的最终判断；否则扩缩容、重启或负载均衡变化会把正确性变成偶然。

3. 哈希、容量与复杂度：为什么是二次幂而不是“魔法常数”

3.1 hash（哈希）扰动、下标计算与懒分配

JDK（Java 开发工具包）8/17/21 的核心扰动是 h ^ (h >>> 16)：先取键的 hashCode（哈希码方法）为 h，再把高 16 位异或进低位。由于桶下标只使用容量掩码覆盖的低位，扰动让高位差异也有机会影响定位。下标为 (n - 1) & hash（哈希），不是通用求余；只有 n 是二次幂时，n - 1 才是低位连续为 1 的掩码。

JDK（Java 开发工具包）7u80 的补充扰动更复杂，并带有 hashSeed（哈希种子）相关分支；不要把 JDK（Java 开发工具包）8 公式说成所有旧版本都使用的公式。两代实现的共同目标都是防止只在高位不同的低质量哈希集中到同一桶。

tableSizeFor（容量取整方法）会把请求容量向上取到不小于它的最小二次幂：通过连续右移并或运算把最高有效位右侧都填成 1，再加 1。例如 10 变 16、17 变 32。new HashMap<>(10) 在 JDK（Java 开发工具包）8+ 中先把 16 暂存到 threshold（扩容阈值），首次写入才真正分配长度 16 的 table（桶数组）；“构造参数是 10”不等于物理数组长度就是 10。

0.75 是空间利用率、碰撞概率和扩容频率之间的工程折中，不是数学最优定理。负载因子更小会更早扩容、耗更多桶数组内存但减少平均桶长度；更大则节省桶空间、增加冲突和 equals（相等判断方法）次数，并使延迟更容易出现尖峰。业务应基于键数量、内存预算和延迟目标估算，而不是机械把所有映射设为 1.0。

热门面试题

1. 问题（基础题）：HashMap（哈希映射）为什么容量通常保持二次幂？

   • 考点：位运算定位与扩容拆分。
   • 回答思路：先解释掩码下标，再说明翻倍后只检查一个新增位。
   • 详细答案：容量为二次幂时，n - 1 的低位连续为 1，(n - 1) & hash（哈希）等价于取哈希的低位作为数组下标，通常比通用取模更直接。更关键的是从 16 翻倍到 32 后，旧桶中每个节点的新下标只有两种：原下标或原下标加 16；判断依据正是 hash & oldCap（哈希与旧容量）。这使迁移能线性扫描节点并拆成两条链，而不必重新做一般除法。该设计的代价是容量取整和桶数组可能有空位。
   • 进阶追问：如果容量不是二次幂，正确性会坏吗？
   • 进阶回答：使用合适的取模仍可以正确定位，不会天然错误；但 JDK（Java 开发工具包）8+ 的掩码公式与低高位拆分前提就不成立，分布和迁移实现都要重写。二次幂是该实现为了快速定位、规律扩容和简单拆分做的工程选择，不是哈希表唯一正确形式。

2. 问题（原理题）：负载因子为什么默认是 0.75，而不是越大越省内存？

   • 考点：空间换时间、冲突概率和扩容频率。
   • 回答思路：明确它是折中，再分别说明太小和太大的代价。
   • 详细答案：负载因子表达“元素数到达容量多少比例后扩容”的目标。取 0.75 让默认容量 16 在 12 个映射后扩容，在桶数组利用率、常见冲突长度和扩容次数之间取得经验折中。更小值会让表更稀疏、查找候选更少，却频繁分配更大数组；更大值会延后扩容、节省桶数组，但链表/树比较更多且一次扩容更昂贵。它不能脱离键的哈希质量、对象大小、请求峰值和堆预算被宣布为“最优”。
   • 进阶追问：批量导入时初始容量如何算？
   • 进阶回答：先确定预计不同键数量 m，按 ceil(m / loadFactor)（向上取整）得到至少容纳该数量而不马上扩容的容量，再向上取到二次幂。例如 1000 个不同键且使用默认负载因子，估算为 1334，实际选择 2048；若实际键远少于预估，会用更多桶数组内存，所以必须有数据上界而不是盲目放大。

3. 问题（项目题）：库存聚合中 HashMap（哈希映射）为什么会慢于预期？

   • 考点：键设计、哈希/相等成本与容量估算。
   • 回答思路：从桶冲突、字符串/对象比较、扩容和并发归并四个角度排查。
   • 详细答案：先确认聚合键是否只包含租户、仓库、SKU（库存单位）等稳定维度，避免把大对象、可变明细或低基数字段直接作为键；低质量 hashCode（哈希码方法）会让冲突桶变长，高成本 equals（相等判断方法）会放大每次比较。再查看不同键数量与初始容量是否匹配，批量开始时多次 resize（扩容）会造成 CPU（中央处理器）和分配峰值。多线程若共享普通 HashMap（哈希映射）则结果不可信，应改为分片私有映射后归并，或在后续章节选用 ConcurrentHashMap（并发哈希映射）。
   • 进阶追问：是否应该把所有业务键都预先计算一个整数哈希？
   • 进阶回答：不应只为“省一次计算”引入新的可变字段或碰撞风险。应先保证业务身份不可变、哈希分布合理和容量正确；若键对象确实重度复用且哈希计算昂贵，可让不可变值对象安全缓存哈希，但必须与参与 equals（相等判断方法）的字段完全一致，不能因状态变化而失效。

4. 从 putVal（内部写入方法）到 resize（扩容）与树化：一次写入发生了什么

4.1 空表、冲突桶、树化阈值与摊还成本

下图对应 JDK（Java 开发工具包）8/17/21 的 putVal（内部写入方法）主线。它是源码实现的简化，不是 Map（映射接口）契约。

flowchart TD
    A["put（写入）键和值"] --> B["计算 hash（哈希）"]
    B --> C{"table（桶数组）为空？"}
    C -->|是| D["resize（扩容）完成首次懒分配"]
    C -->|否| E["计算 i = (n - 1) & hash（哈希）"]
    D --> E
    E --> F{"桶 i 为空？"}
    F -->|是| G["写入 Node（节点）"]
    F -->|否| H{"首节点键相等？"}
    H -->|是| I["覆盖 value（值），不增加 size（大小）"]
    H -->|否| J{"TreeNode（树节点）桶？"}
    J -->|是| K["在红黑树查找或插入"]
    J -->|否| L["遍历链表；尾部追加或找到相等键"]
    L --> M{"达到树化检查点？"}
    M -->|是| N["treeifyBin（桶树化方法）：容量不足 64 时优先扩容"]
    M -->|否| O["结束桶内处理"]
    G --> P["modCount（结构修改计数）递增，size（大小）递增"]
    K --> P
    O --> P
    P --> Q{"size（大小）超过 threshold（扩容阈值）？"}
    Q -->|是| R["resize（扩容）"]
    Q -->|否| S["返回旧值或 null（空值）"]
    R --> S

逐步解读：

1. 默认构造的 table（桶数组）为 null（空值），首次 put（写入）由 resize（扩容）分配容量 16，阈值 12。
2. 空桶直接生成 Node（节点）；非空桶先以哈希和引用/equals（相等判断方法）判断是否为同键，命中只覆盖 value（值），不改变 size（大小）和 modCount（结构修改计数）。
3. 不同键的普通冲突桶尾部追加。原桶已有 8 个节点时，追加第 9 个节点后才会调用 treeifyBin（桶树化方法）；该调用不等于必然树化，因为它还要检查总容量。
4. 真正新增后才递增 size（大小）；若 size > threshold（扩容阈值）才触发扩容。因此“第 13 个默认元素”是在写入完成后使 12 的阈值被超过。

TreeNode（树节点）不仅有键、值、哈希和后继引用，还维护父、左、右、前驱和颜色等信息，所以它只在极端冲突桶中值得付出更多内存和维护成本。树化不是修复坏哈希的万能药：它降低单桶搜索退化，却不能消除昂贵 equals（相等判断方法）、大量对象分配或恶意输入的整体压力。

简化 putVal（内部写入方法）伪代码：
hash = key == null ? 0 : (h = key.hashCode()) ^ (h >>> 16)
if table 还未分配：resize()
i = (table.length - 1) & hash
if table[i] 为空：table[i] = 新 Node
否则：在首节点、TreeNode 或链表中找相等 key
      找到：覆盖 value 并返回旧值
      未找到：追加新节点；必要时 treeifyBin()
modCount++；size++
若 size > threshold：resize()

热门面试题

1. 问题（基础题）：HashMap（哈希映射）的 put（写入）流程如何讲？

   • 考点：懒分配、桶定位、覆盖、新增、树化与扩容。
   • 回答思路：按“算哈希—初始化—定位—比较—写入—计数—扩容”顺序复述。
   • 详细答案：JDK（Java 开发工具包）8+ 的 put（写入）先调用 hash（哈希）取得扰动后的值；若 table（桶数组）尚未分配，resize（扩容）完成首次容量初始化。随后以 (n - 1) & hash（哈希）找到桶：空桶直接放入 Node（节点）；非空桶先比较首节点，再分为 TreeNode（树节点）查找或链表遍历。相等键只覆盖 value（值），不增加大小；不同键新增后才递增 modCount（结构修改计数）和 size（大小），超过 threshold（扩容阈值）才触发扩容。链表过长会请求树化，但容量不足 64 时先扩容。
   • 进阶追问：覆盖一个已有键的值为什么通常不触发 fail-fast（快速失败）？
   • 进阶回答：JDK（Java 开发工具包）8+ 的覆盖路径不增加 modCount（结构修改计数），因为键集合和桶拓扑没有结构性变化；迭代器主要用该计数尽力发现结构修改。它不是线程安全保证：并发覆盖仍没有可见性或复合操作原子性，且 fail-fast（快速失败）机制本来就只用于尽早暴露错误使用。

2. 问题（原理题）：8、6、64 三个树化数字应该如何准确解释？

   • 考点：树化门槛、优先扩容和退化边界。
   • 回答思路：分别说明树化检查点、最小数组容量与拆分退化，再强调删除路径不只看计数。
   • 详细答案：8 是 TREEIFY_THRESHOLD 常量；在普通链表尾插路径，原桶已有 8 个节点时，追加第 9 个节点后才满足 binCount >= 7 并调用 treeifyBin（桶树化方法）。64 是 MIN_TREEIFY_CAPACITY，表示整个 table（桶数组）长度小于 64 时该调用不树化而优先扩容，因为小表中的碰撞常可通过重新分桶缓解；6 是 UNTREEIFY_THRESHOLD，用于扩容拆分后小组退回普通节点，避免稀疏红黑树的额外开销。删除树节点时源码还观察树形是否过于稀疏等结构条件，不能背成“元素剩 6 个必然立刻退化”。
   • 进阶追问：为什么不把所有桶从一开始就实现成红黑树？
   • 进阶回答：正常哈希分布下绝大多数桶为空或只含少量节点，简单 Node（节点）链表更省内存、代码路径更短、遍历更友好。红黑树需要更多引用和旋转/着色维护，小桶反而更慢；延迟树化把昂贵结构留给极端冲突，是以常见路径轻量换取坏路径有上界的设计。

3. 问题（项目题）：IoT（物联网）报警聚合出现 CPU（中央处理器）升高，如何判断是否与冲突桶有关？

   • 考点：证据链、键分布、树化与业务止血。
   • 回答思路：先看火焰图/线程栈，再抽样键与哈希分布，最后处理输入、容量和限流。
   • 详细答案：先用 CPU（中央处理器）火焰图或线程栈确认热点是否落在 hashCode（哈希码方法）、equals（相等判断方法）、HashMap.getNode（哈希映射取节点方法）或树比较，而不是先猜树化。再按报警键抽样统计不同键数、同一哈希值占比、单桶链长或树桶数量，并检查是否把设备对象、可变标签集合或低基数告警码作为键。止血可按租户/设备分片、限制窗口键数、限流和丢弃可降级通知；长期修复是使用不可变且分布良好的 deviceId + alarmCode + ruleVersion（设备标识加报警编码加规则版本）键，并把跨实例窗口放到 Redis（远程字典服务）或流处理分区。
   • 进阶追问：树化后 CPU（中央处理器）一定会恢复吗？
   • 进阶回答：不一定。树化只改善单桶节点定位的增长阶，仍要计算哈希、执行业务相等比较、分配报警对象和清理窗口；若所有请求都集中到一个设备键，热点值更新、锁竞争或下游通知同样可能主导 CPU（中央处理器）。必须以采样证据确认瓶颈，并同时设置键空间上限和入站背压。

5. 数据演绎：16 扩到 32、相等契约与可变键如何改变结果

5.1 低高位拆分、冲突与失联键

从容量 16 扩到 32 时，旧掩码是 0x0F，新掩码是 0x1F。新掩码只多检查第 5 个二进制位，即 oldCap = 16 对应的位。若 hash & 16 为 0，节点留在原索引；否则移动到“原索引 + 16”。JDK（Java 开发工具包）8+ 对普通链表分别建立低位和高位子链，保留每个子链内部顺序。

flowchart LR
    O["旧桶 j = 3，容量 16"] --> A["A：hash（哈希）0x03，0x03 & 0x10 = 0"]
    O --> B["B：hash（哈希）0x13，0x13 & 0x10 = 0x10"]
    O --> C["C：hash（哈希）0x23，0x23 & 0x10 = 0"]
    O --> D["D：hash（哈希）0x33，0x33 & 0x10 = 0x10"]
    A --> L["新桶 3：A → C"]
    C --> L
    B --> H["新桶 19：B → D"]
    D --> H

这也是二次幂扩容的价值：四个节点不需重新执行“除以 32 取余”，只需看同一个旧容量位。请注意，表中 0x03 等是扰动后的哈希值，不是任意业务对象原始 hashCode（哈希码方法）的保证值。

sequenceDiagram
    participant W as WMS（仓储管理系统）聚合线程
    participant M as HashMap（哈希映射）
    participant K as 可变库存键
    W->>M: put（写入）(K{仓库=8}, 12)
    M-->>W: 节点留在旧桶 4
    W->>K: 把仓库改为 9
    W->>M: get（读取）(K{仓库=9})
    M-->>W: 按新 hash（哈希）定位桶 14，未找到
    Note over M,K: 节点没有自动迁移；遍历找回只会掩盖契约错误

热门面试题

1. 问题（基础题）：HashMap（哈希映射）从 16 扩到 32 时，节点为什么只会留在原位或移动 16？

   • 考点：二次幂掩码与旧容量位。
   • 回答思路：比较旧新掩码，再用 hash & oldCap（哈希与旧容量）给出两种去向。
   • 详细答案：容量 16 的下标使用哈希低 4 位，容量 32 多使用一位；新增的正是数值 16 对应的位。因此旧桶下标为 j 的节点，在新表中若 hash & 16 为 0，低 4 位不变且新增位为 0，仍在 j；若该位为 1，则下标变为 j + 16。JDK（Java 开发工具包）8+ 用低位/高位两条链完成拆分，链表内部相对顺序不被反转。这个规律依赖容量翻倍且始终为二次幂。
   • 进阶追问：树桶扩容时也只分为两组吗？
   • 进阶回答：是的，TreeNode（树节点）也按同一旧容量位拆成低位和高位组；每组在新表中可继续保留树结构，或在节点数不大于 UNTREEIFY_THRESHOLD 时转回普通链表节点。树形与链表的后续结构不同，但下标去向规则相同。

2. 问题（原理题）：相等对象哈希不同与哈希相同对象不等，分别有什么后果？

   • 考点：必要条件、充分条件与两阶段定位。
   • 回答思路：先说明“相等必同哈希”，再区分正常冲突和契约破坏。
   • 详细答案：equals（相等判断方法）为真的两个对象必须返回同一 hashCode（哈希码方法），否则它们会被哈希定位分到不同桶，HashMap（哈希映射）不会到另一个桶继续比较，覆盖和查找都可能失败，HashSet（哈希集合）也会保存逻辑重复项。反过来，哈希相同只说明候选桶相同，不代表业务相等；容器会继续调用 equals（相等判断方法），把不同对象保留为同桶的多个节点。前者破坏正确性，后者是哈希有限空间中的正常现象，只可能影响性能。
   • 进阶追问：为什么不能让所有对象返回常量哈希来“避免算错”？
   • 进阶回答：常量哈希仍满足“相等对象同哈希”，所以通常不会直接破坏语义，但所有键集中到一个桶，链表或树比较成为瓶颈，写入和查找会显著退化并可能造成 CPU（中央处理器）热点。正确做法是让稳定身份字段参与哈希并有合理分布，同时保留 equals（相等判断方法）做精确确认。

3. 问题（项目题）：库存聚合键变更后查不到原记录，怎样止血和根治？

   • 考点：可变键证据、数据修复与不可变建模。
   • 回答思路：先停止原地修改和重建当前批次映射，再将键收敛为不可变值对象。
   • 详细答案：排查时记录写入/读取的键字段、hashCode（哈希码方法）、表容量和下标，证明同一对象或业务身份的定位是否变化；不能靠遍历全表“捞回”节点，因为这只把错误转成偶发线性扫描。止血是在当前批次停止修改已入表对象，重新以稳定的 skuId + warehouseId + ownerId（库存单位标识加仓库标识加货主标识）快照建立映射并校验汇总结果。根治是把键做成不可变值对象，只让身份字段参与相等与哈希，状态、数量、更新时间放入值或独立聚合对象。
   • 进阶追问：为什么这个问题可能只在扩容后才明显？
   • 进阶回答：修改后的哈希有时碰巧仍命中旧桶，或者小容量掩码尚未使用发生变化的高位，使问题被掩盖；扩容后新增参与下标的位可能把读路径分到另一个桶，于是开始稳定失败。扩容不是根因，而是让原本已被破坏的相等契约更容易显形。

6. HashSet（哈希集合）：复用 HashMap（哈希映射）的键唯一性，而不制造顺序保证

6.1 PRESENT（共享占位对象）、去重映射与适用边界

JDK（Java 开发工具包）8/21 的 HashSet（哈希集合）内部保存 HashMap<E, Object>；add（添加）等价于 map.put(element, PRESENT)（映射写入元素与占位对象），remove（移除）等价于移除该键，contains（判断包含）等价于判断底层是否存在该键。PRESENT（共享占位对象）是同一个私有对象，因为集合不需要为每个元素保存有意义的值。

图中从左到右依次表达：

1. table（桶数组）有空桶、链表桶和 TreeNode（树节点）桶；键和值都保存于节点。
2. 空桶不需要节点；少量冲突沿 next（后继引用）形成链表；极端冲突桶在满足容量条件后可组织为红黑树。
3. 扩容时旧桶 j 拆到新桶 j 与 j + oldCap（新桶原位与偏移位置），不是任意散射；低位和高位由 hash & oldCap（哈希与旧容量）判定。

HashSet（哈希集合）允许一个 null（空值）元素，因为底层 HashMap（哈希映射）允许 null（空值）键。它不能保证顺序，也不能把元素复制成快照：入集合后修改参与相等/哈希的字段，一样会造成“集合里有却查不到”的失联问题。

热门面试题

1. 问题（基础题）：HashSet（哈希集合）为什么能去重？

   • 考点：键唯一性与共享占位对象。
   • 回答思路：把元素看作底层映射的键，说明 PRESENT（共享占位对象）和相等契约。
   • 详细答案：HashSet（哈希集合）不需要独立发明去重算法，它复用 HashMap（哈希映射）的键唯一性：添加元素时把元素作为键，值统一写入 PRESENT（共享占位对象）。若底层按哈希定位后发现相等键，put（写入）只覆盖同一个占位值而不增加大小，add（添加）返回假；否则新增节点，add（添加）返回真。因此去重由 hashCode（哈希码方法）和 equals（相等判断方法）共同定义，不是按内存地址、日志文本或数据库行号自动去重。
   • 进阶追问：HashSet（哈希集合）中能有两个哈希相同的元素吗？
   • 进阶回答：能。哈希相同但 equals（相等判断方法）为假的两个元素属于正常碰撞，会共同留在同一桶的链表或树中；只有相等键才被视作重复。真正错误是相等元素的哈希不同，它们会进入不同桶并同时存在，表面看起来像“集合去重失效”。

2. 问题（原理题）：为什么 HashSet（哈希集合）不保证迭代顺序？

   • 考点：桶下标、扩容迁移与实现边界。
   • 回答思路：说明迭代跟随底层桶和节点，而桶布局会变化。
   • 详细答案：普通 HashSet（哈希集合）的迭代器来自底层 HashMap（哈希映射）的键集合，遍历通常按桶数组和桶内节点进行；下标受哈希值、容量和扩容历史影响。一次 resize（扩容）就可能让节点从原桶移动到偏移桶，所以同一批元素的遍历顺序不应作为业务协议或测试断言。若要保留插入顺序使用 LinkedHashSet（链式哈希集合），若要排序使用 TreeSet（树集合），并分别承担额外链接或排序成本。
   • 进阶追问：为什么某次运行的 HashSet（哈希集合）顺序“看起来稳定”？
   • 进阶回答：固定 JDK（Java 开发工具包）版本、固定元素、固定哈希和固定容量时，内部遍历路径可能恰好重复，但这仍不构成 API（应用程序接口）承诺。元素增删、扩容、键实现变化或运行时版本变化都可改变顺序；依赖这种偶然稳定性会让序列化、签名、报表和测试产生脆弱故障。

3. 问题（项目题）：IoT（物联网）报警窗口用 HashSet（哈希集合）去重时，怎样避免误去重和 OOM（内存溢出）？

   • 考点：去重语义、容量/时间边界与跨实例责任。
   • 回答思路：先定义键和窗口，再设置容量/过期，最后把跨实例事实放到外部系统。
   • 详细答案：先明确“同租户、同设备、同报警码、同规则版本在 60 秒内合并”这一语义，把这些稳定维度生成不可变键；不要把告警状态、次数或更新时间混入键。单实例 HashSet（哈希集合）必须有最大键数、时间轮换或定时过期清理，并监控键数、淘汰数和输入速率，防止报警风暴把堆填满。多实例下本地集合只能降噪，跨实例窗口去重需要 Redis（远程字典服务）的原子过期写入或按键分区的流处理，同时原始报警仍要持久化以供审计。
   • 进阶追问：为什么不能用 hashCode（哈希码方法）本身作为报警去重键？
   • 进阶回答：整数哈希可能碰撞，碰撞只能用于缩小候选范围，不能代表业务身份；把它当唯一键会把不同设备或告警误合并。应保存完整的规范化业务键，必要时用哈希做索引或分片，但最终去重仍需完整字段比较或外部存储的唯一约束。

7. 并发边界、历史成环与线上排查：普通 HashMap（哈希映射）不承担同步责任

7.1 丢更新、可见性、JDK（Java 开发工具包）7 成环与诊断路径

普通 HashMap（哈希映射）没有为多线程共享写入提供同步协议。风险不只是一句“线程不安全”：两个线程可能同时写同一空桶导致一个节点覆盖另一个节点；size（大小）和 modCount（结构修改计数）更新不是并发原子协议；没有同步发布时，一个线程对桶数组、节点后继或值的修改对另一线程何时可见也没有保证。迭代器的 fail-fast（快速失败）只尽力检测结构修改，不能作为锁，更不能证明没有数据竞争。

JDK（Java 开发工具包）7u80 的经典成环来自 transfer（迁移方法）对链表的头插。设旧桶为 A → B：线程一读到 A 且保存 next=B 后暂停；线程二完整迁移，得到新桶 B → A；线程一恢复，将 A 头插到当前新桶后继续处理 B，此时读到 B 的后继又是 A，于是可能再次处理 A/B 并让链表闭环。之后某个 get（读取）沿 next（后继引用）可能无限循环并拉高 CPU（中央处理器）。这是历史实现和特定交错的精确路径，不是所有 JDK（Java 开发工具包）版本都会出现的同一结构性缺陷。

flowchart TD
    A["发现 HashMap（哈希映射）热点或结果不一致"] --> B{"是否共享给多个线程写？"}
    B -->|是| C["停止把普通映射作为共享可变状态"]
    C --> D{"是否仅单机临时聚合？"}
    D -->|是| E["每线程私有 HashMap（哈希映射）后归并"]
    D -->|否| F["选择 ConcurrentHashMap（并发哈希映射）或持久化协调"]
    B -->|否| G{"键数量是否无界或键可变？"}
    G -->|是| H["设容量/过期；使用不可变键；采集堆证据"]
    G -->|否| I["检查 hashCode（哈希码方法）与 equals（相等判断方法）成本"]
    F --> J["支付/库存仍由唯一约束、条件更新、状态机兜底"]

热门面试题

1. 问题（基础题）：HashMap（哈希映射）为什么线程不安全？

   • 考点：竞争写入、可见性和结构变更。
   • 回答思路：分别讲丢更新、内存可见性和迭代/扩容结构风险。
   • 详细答案：HashMap（哈希映射）没有用锁或原子协议保护桶数组、节点引用、size（大小）和 modCount（结构修改计数）。两个线程可同时判断某桶为空并分别写入，后写引用覆盖前写；多个线程对同一值做“读取—计算—写回”也会丢失业务更新。没有同步建立 happens-before（先行发生）关系时，读线程还不能假设马上看见写线程的节点和字段更新。扩容、链表/树修改与迭代同时发生会扩大中间状态窗口；fail-fast（快速失败）不是同步机制。
   • 进阶追问：给 HashMap（哈希映射）外层加 synchronized（同步锁）是否可行？
   • 进阶回答：在所有读写、迭代和复合操作都严格使用同一把锁的前提下可以保证正确性，但吞吐会受整张表锁限制，迭代期间也需持锁或先复制快照。多数共享映射场景更适合 ConcurrentHashMap（并发哈希映射）及其 compute（计算更新方法）等原子操作；跨实例正确性仍不能由任何本地锁解决。

2. 问题（原理题）：JDK（Java 开发工具包）7 的 HashMap（哈希映射）成环是怎样发生的？

   • 考点：transfer（迁移方法）、头插与交错时序。
   • 回答思路：给出 A→B 旧链、两个迁移线程和后继引用被改写的顺序。
   • 详细答案：JDK（Java 开发工具包）7u80 的 transfer（迁移方法）保存当前节点的后继，再把当前节点头插到新桶。旧链 A → B 上，线程一保存 A 的后继 B 后暂停；线程二先迁移 A、再迁移 B，新桶变为 B → A；线程一恢复后把 A 再头插到当前新桶并继续 B，读取到的 B 后继已经是 A，于是 A/B 可能被反复接回，形成闭环。之后查找沿 next（后继引用）前进无法到达 null（空值），表现为 CPU（中央处理器）持续空转。该路径依赖旧版头插迁移和无同步交错。
   • 进阶追问：JDK（Java 开发工具包）8 为什么不能再用“会成环”概括？
   • 进阶回答：JDK（Java 开发工具包）8 的普通链表扩容改为低高位拆分，并显式截断两条尾链以保持顺序，不再是 JDK（Java 开发工具包）7 的同一头插 transfer（迁移方法）路径。因此应准确说“JDK（Java 开发工具包）7 有已知成环历史路径；JDK（Java 开发工具包）8+ 仍非线程安全，可能丢更新、可见性错误或结构观察异常”，而不是把历史故障当成每个版本的必然现象。

3. 问题（项目题）：Runner（执行器）多线程本地状态为何不能直接用 HashMap（哈希映射）？

   • 考点：进程内并发、服务重启与任务最终状态。
   • 回答思路：先说明普通映射的竞争，再把临时状态和业务状态拆开。
   • 详细答案：Runner（执行器）的多个工作线程若共享普通 HashMap（哈希映射）记录任务状态，会同时触发空桶竞争、丢更新和不可见状态，造成任务看似未执行、重复领取或监控数不准。进程内临时句柄可使用 ConcurrentHashMap（并发哈希映射）并在任务结束及时清理；待执行、领取中、成功、失败和重试次数等业务事实必须落库，以条件更新抢占任务并记录版本或租约。服务重启、多实例调度和重复投递时，再由任务号幂等和状态机限制副作用。
   • 进阶追问：只把 HashMap（哈希映射）替换为 ConcurrentHashMap（并发哈希映射）是否就能防重复执行？
   • 进阶回答：不能。它只协调同一 JVM（Java 虚拟机）内的并发访问，不能让其他实例看到状态，也无法在进程宕机后恢复。防重复执行需要持久化领取条件、租约超时回收、任务业务键幂等和必要的对账；并发容器只是本地加速和协调工具。

8. 项目落地、堆排查与复习清单

8.1 从内存结构到业务保障：库存、支付、报警与本地缓存

本地 Map（映射接口）/Set（集合接口）必须把资源边界写成代码和指标：最大条目数、最大驻留时间、单条大小、清理策略、写入速率、淘汰数和堆占用。无界增长常先表现为老年代占用上升、GC（垃圾回收）频率升高和请求延迟抖动，最后才是 OOM（内存溢出）；“把堆调大”只能延后问题，不能修复无界键空间或漏清理。

可复述项目话术。 在 WMS（仓储管理系统）库存聚合中，我把租户、货主、仓库和 SKU（库存单位）组成不可变聚合键，单批次根据不同键数估算 HashMap（哈希映射）容量；并行批次先在线程私有映射中聚合，再归并以消除共享写竞争。这个映射只计算过程数据，库存防超卖仍依赖数据库“可售量足够才扣减”的条件更新、库存流水唯一业务号与订单状态机。支付回调和 IoT（物联网）报警同理：HashSet（哈希集合）只做本实例、有限窗口的快速拦截；跨实例幂等、持久化和恢复交给唯一约束、Redis（远程字典服务）原子操作、状态机及对账，而不是相信内存命中。

热门面试题

1. 问题（基础题）：本地 HashMap（哈希映射）缓存最容易忽略的风险是什么？

   • 考点：无界增长、实例隔离与失效边界。
   • 回答思路：分别说资源上限、生命周期和多实例数据分叉。
   • 详细答案：本地 HashMap（哈希映射）直接占用应用堆，若键数或值对象无上限，会与请求、线程栈和业务对象争抢内存，最终引发 GC（垃圾回收）抖动或 OOM（内存溢出）。每个实例还拥有自己的副本，扩缩容、重启、灰度和请求路由都会改变命中，更新后也需要明确失效传播。它适合有限、可再生、允许短暂不一致的热点派生数据；不能用作共享锁、全局幂等记录或唯一业务事实。
   • 进阶追问：发生 OOM（内存溢出）后如何证明是某个 Map（映射接口）导致？
   • 进阶回答：保留 Heap（堆）转储，用 MAT（内存分析工具）查看支配树，找到占用最大的 HashMap（哈希映射）/HashSet（哈希集合）及其键和值对象，再沿到垃圾回收根引用链确认是谁持有它；结合条目数、写入速率、淘汰数和任务批次日志判断是无界键、值过大还是未清理。先限流、暂停或清理可再生数据止血，再补容量、过期和生命周期测试，而不是只提高 Xmx（最大堆内存）。

2. 问题（原理题）：为什么说 HashMap（哈希映射）体现了分治与摊还设计？

   • 考点：数组定位、桶内冲突结构和偶发扩容成本。
   • 回答思路：先拆分“大量键查找”，再解释常见路径与少数昂贵路径的平均关系。
   • 详细答案：哈希把大量键按数组下标分治到不同桶，正常查找先在数组进行一次快速定位，只在局部桶处理碰撞；链表保持少量节点的低开销，红黑树保护极端桶不无限线性退化。扩容把一次全量迁移成本集中在少数写入上，但随着容量翻倍，前面多次普通写入共同分担这次成本，因此连续追加的平均成本可看作摊还低成本。代价是扩容瞬间存在延迟和内存峰值，且哈希质量差会削弱分治效果。
   • 进阶追问：摊还低成本能否用于承诺每次请求的低延迟？
   • 进阶回答：不能。摊还分析只说明长序列的平均成本，单次 resize（扩容）仍可能迁移大量节点、分配新数组并触发 GC（垃圾回收）压力。对延迟敏感的批处理或在线路径，应预估初始容量、分批处理、限制单次聚合集合大小，并用压测观察 P99（99 分位响应时间）而非只看平均值。

3. 问题（项目题）：如何把“内存去重”正确接入支付与库存方案？

   • 考点：性能层与事实层分离、失败恢复。
   • 回答思路：给出本地快速过滤、持久化原子判决、状态机和补偿的分层。
   • 详细答案：接入层可用有界 HashSet（哈希集合）或本地 Map（映射接口）快速过滤同实例的瞬时重复请求，降低无效验签、查询和下游调用；但每个请求仍要进入持久化原子判决。支付以渠道事件标识建立唯一约束，只有首个事务推进支付状态并写账务/待发送事件；库存以库存流水唯一业务号和“可售量满足条件才更新”的条件更新防止超卖，订单状态机限制重复迁移。缓存或 Redis（远程字典服务）故障、服务重启和消息重复时，持久化约束保证系统还能恢复正确结论。
   • 进阶追问：为什么数据库唯一约束还不够？
   • 进阶回答：唯一约束只能判定同一业务键是否首次出现，不能独自表达库存数量下限、支付状态合法迁移、外部调用超时后的补偿或消息最终投递。它要与条件更新、状态机、事务内待发送事件、重试幂等和对账组合；每一层都承担不同失败窗口，不能把“唯一”误当成全部一致性。

9. 复习清单

• 能先分层回答 Map（映射接口）契约、HashMap（哈希映射）实现与 HotSpot（热点虚拟机）运行时边界。
• 能准确对比 JDK（Java 开发工具包）7 的 Entry（条目节点）头插迁移、JDK（Java 开发工具包）8+ 的 Node（节点）/TreeNode（树节点）和低高位拆分。
• 能写出 JDK（Java 开发工具包）8+ 的 h ^ (h >>> 16) 扰动、(n - 1) & hash（哈希）定位与 tableSizeFor（容量取整方法）的设计目的。
• 能解释默认容量 16、负载因子 0.75、阈值 12、懒分配以及 8/6/64 的精确边界。
• 能用四个具体哈希值推演容量 16 到 32 时留在原位或移动 16，并说明组内顺序保持。
• 能区分“相等对象哈希不同”的正确性故障与“哈希相同对象不等”的正常碰撞。
• 能解释 HashSet（哈希集合）的 PRESENT（共享占位对象）代理模型、无顺序保证和可变元素风险。
• 能复述 JDK（Java 开发工具包）7 成环的 A→B 交错路径，同时明确 JDK（Java 开发工具包）8+ 仍不能并发写。
• 能把 WMS（仓储管理系统）聚合、支付幂等、IoT（物联网）报警和本地缓存的内存职责与数据库/Redis（远程字典服务）最终责任分开。

10. 版本与参考来源

• 本机 JDK（Java 开发工具包）8 src.zip：/Users/Lever/Library/Java/JavaVirtualMachines/corretto-1.8.0_402/Contents/Home/src.zip，核对 java/util/HashMap.java 与 java/util/HashSet.java 的 putVal（内部写入方法）、resize（扩容）、treeifyBin（桶树化方法）、PRESENT（共享占位对象）。
• 本机 JDK（Java 开发工具包）21 src.zip：/Users/Lever/Library/Java/JavaVirtualMachines/openjdk-21.0.2/Contents/Home/lib/src.zip，核对 java.base/java/util/HashMap.java 与 java.base/java/util/HashSet.java；核心桶、树化和拆分路径延续。
• 本机未找到 JDK（Java 开发工具包）17 src.zip；以 OpenJDK（开放 Java 开发工具包）17u 固定标签 HashMap（哈希映射）源码 核对 17 的核心常量和路径。
• OpenJDK（开放 Java 开发工具包）JDK（Java 开发工具包）7u80-b15 固定标签 HashMap（哈希映射）源码：核对 Entry（条目节点）、头插与 transfer（迁移方法）。
• JDK（Java 开发工具包）21 HashMap（哈希映射）API（应用程序接口） 与 JDK（Java 开发工具包）21 HashSet（哈希集合）API（应用程序接口）：核对公开契约与顺序/线程边界。