集合-Map-IdentityHashMap

概述

在 Java 集合框架的 Map 家族中，IdentityHashMap 是一个刻意的“反叛者”。它公然违背 Map 接口的通用契约，用引用相等（==）替代 equals 方法来判断键的唯一性，并基于 System.identityHashCode 进行哈希。这种看似“不合群”的设计背后，隐藏着对对象身份精确追踪的迫切需求——无论是序列化引擎中的循环引用处理，还是基于 Class 对象的安全缓存，IdentityHashMap 都扮演着不可替代的角色。本文将深入剖析这一专用容器的设计哲学，从其独特的引用相等语义、开放寻址双数组存储结构，到线性探测的滞后删除算法，结合 JDK 8 源码，全方位解读它如何在小众场景中大放异彩。

核心知识点提炼：

• 引用相等（==）而非 equals：比较键（和值）时使用 == 判断对象是否同一，而非 equals，故意违反 Map 接口的语义约定，用于需要精确标识对象身份的场景。
• 开放寻址法的双数组存储：底层使用单个 Object[] table，索引为偶数存储 key、奇数存储 value，通过线性探测解决哈希冲突，无链表或树结构。
• 基于 System.identityHashCode 的哈希：键的哈希值使用 System.identityHashCode（无论 hashCode 方法是否被重写），保证同一对象的哈希稳定且不可伪造。
• 特殊的 null 处理：允许 null 键和 null 值，null 键的哈希固定为 0；由于 == 语义，只能存在一个 null 键。
• 紧凑内存与无额外对象开销：没有 Node 包装类，键值直接存储在数组中，避免了大量小对象的内存开销，但需注意扩容时的搬移成本。

全文组织架构图：

flowchart TD
    subgraph S1["Part 1: 基础认知篇"]
        A1["模块1: 定义、核心特性与适用场景"]
        A2["模块2: 接口与继承体系"]
    end
    subgraph S2["Part 2: 存储与构造篇"]
        B1["模块3: 存储结构与核心字段"]
        B2["模块4: 构造方法"]
    end
    subgraph S3["Part 3: 核心原理篇"]
        C1["模块5: 哈希计算与索引定位"]
        C2["模块6: put 操作——线性探测插入"]
        C3["模块7: remove 操作——滞后清除"]
        C4["模块8: get 与 containsKey/Value"]
        C5["模块9: 扩容机制"]
    end
    subgraph S4["Part 4: 特性与约束篇"]
        D1["模块10: 违背 Map 契约的设计意图"]
        D2["模块11: 与 HashMap 的精细对比"]
    end
    subgraph S5["Part 5: 陷阱与实践篇"]
        E1["模块12: 常见陷阱与最佳实践"]
    end
    subgraph S6["Part 6: 总结与面试篇"]
        F1["模块13: 性能总结"]
        F2["模块14: 面试高频专题"]
    end

    S1 --> S2 --> S3 --> S4 --> S5 --> S6

图表说明：

• 第一层（宏观结构）：全文划分为六大篇章，采用递进逻辑。从基础认知出发，先让读者理解 IdentityHashMap 是什么、为何存在；再深入到内部存储布局与构造；接着剖析核心操作的源码实现；随后讨论它如何故意违背 Map 契约以及和 HashMap 的差异；然后通过陷阱和最佳实践指导实战；最后落脚于性能总结与系统化的面试专题。
• 第二层（篇章内模块关联）：每个篇章内的模块相互支撑。例如“核心原理篇”中，哈希计算模块是 put/get/remove 的基础，而扩容又是这些操作维持性能的关键。这种层层递进的组织方式确保读者能够由表及里、由概念到实现地掌握 IdentityHashMap。
• 第三层（数据结构映射）：S1 到 S6 的箭头体现了从定义 → 结构 → 算法 → 对比 → 实践 → 总结的学习路径，符合技术深度学习的一般规律。

---

Part 1：基础认知篇

模块 1：定义、核心特性与适用场景

IdentityHashMap 的官方定义如下：它实现了 Map 接口，但在比较键和值时刻意使用引用相等（==）而非 equals。这意味着只有在两个键是同一个对象实例（内存地址相同）时，它们才被认为是“相等”的。其设计目的非常明确：为那些需要区分对象身份而非对象内容的场景提供一种高效的映射实现。

核心特性列表：

• 引用相等（Reference Equality）：key1 == key2 判定键的唯一性，value1 == value2 用于 containsValue 和值替换等操作。这是其最根本的语义特征。
• 开放寻址线性探测：底层采用线性探测的开放寻址法解决哈希冲突，不使用链表或红黑树。数据直接存储在 Object[] 数组中。
• 基于 System.identityHashCode 的哈希：哈希值不依赖 hashCode()，而是通过本地方法 System.identityHashCode(Object x) 获取，该值由 JVM 根据对象的内存地址或某种唯一标识生成，即便对象重写了 hashCode() 也不会改变。
• 允许 null 键和值：null 键的哈希固定为 0，且因为 == 判断，只能有一个 null 键（所有 null == null 为 true）。
• 非线程安全：没有内置任何同步机制，多线程并发修改需外部同步，且修改结构会触发 ConcurrentModificationException。
• 故意违反 Map 契约：其 equals、hashCode 等方法不遵循一般 Map 的对称性与传递性要求，文档中明确声明了这一点。

适用场景（按重要性排序）：

1. 序列化和深拷贝中的对象身份跟踪：ObjectOutputStream 在处理对象图时，使用 IdentityHashMap 记录已序列化的对象，防止循环引用导致无限递归。通过 == 比对象实例，即使对象内容相同，只要是不同实例就需要分别记录。
2. Class 实例映射：java.lang.reflect 包中常用 IdentityHashMap 缓存 Class 相关的元数据，因为 Class 对象是单例的（同一个类加载器内），使用 == 既安全又高效。
3. 基于对象身份的缓存：当你需要缓存某些对象自身的计算结果，而不想让所有内容相等的对象共享缓存时，IdentityHashMap 能确保缓存与特定实例绑定。
4. 拓扑图去重或状态标记：在实现图算法时，如果需要将节点对象本身作为键，并标记其访问状态，IdentityHashMap 可以避免因为节点内容相同而错误合并不同节点的状态。
5. ThreadLocal 线程本地存储：JDK 的 ThreadLocal 内部就使用了 ThreadLocalMap（一个自定义的哈希表，语义与 IdentityHashMap 相似）来关联线程与值。

反例场景：

• 需要按 equals 比较内容的常规映射：如根据字符串查找配置，必须使用 HashMap。
• 需要排序：使用 TreeMap。
• 高并发环境：使用 ConcurrentHashMap。

Mermaid 流程图：IdentityHashMap 特性与适用场景决策树

graph TD
    Start["是否需要映射"] --> Condition{"键的唯一性基于对象内存地址"}
    Condition -->|"是"| Size{"规模是否较小且对内存敏感"}
    Size -->|"是"| UseIDHM["使用 IdentityHashMap 注意对象生命周期"]
    Size -->|"否"| UseIDHM_Still["仍可使用 IdentityHashMap 但要关注线性探测退化"]
    Condition -->|"否"| EqContent{"是否需要基于 equals 比较内容"}
    EqContent -->|"是"| Order{"是否需要排序"}
    Order -->|"是"| UseTree["使用 TreeMap"]
    Order -->|"否"| Concurrent{"是否高并发"}
    Concurrent -->|"是"| UseCHM["使用 ConcurrentHashMap"]
    Concurrent -->|"否"| UseHM["使用 HashMap"]
    EqContent -->|"否"| UseOther["考虑其他专用 Map 或 Set"]

图表说明：

• 一句话概括：该决策树引导开发者在不同映射需求下判断是否适用 IdentityHashMap。
• 逐层分解：
  • 第一层（根本分歧）：判断键的唯一性是否必须基于对象内存地址。IdentityHashMap 的核心适用点就是需要区分同一内容的不同对象。
  • 第二层（性能考量）：如果确认需要引用相等，需要考虑规模和数据特征。小规模或中等规模下 IdentityHashMap 内存优势明显，但负载因子较高时线性探测可能带来 O(n) 退化。
  • 第三层（替代方案）：当不需要引用相等时，根据排序、并发等需求顺次选择 TreeMap、ConcurrentHashMap 或普通的 HashMap。
• 关键结论强调：IdentityHashMap 不是 HashMap 的替代品，它只专攻对象身份追踪这一细分领域。误用于常规内容比较会导致难以调试的 bug。

---

模块 2：接口与继承体系

IdentityHashMap 的类层级结构相对简单，但它在继承 AbstractMap 的同时，又故意不与 Map 接口的通用约定完全兼容。

继承链：java.lang.Object → java.util.AbstractMap<K,V> → java.util.IdentityHashMap<K,V>

实现的接口：Map<K,V>, java.io.Serializable, java.lang.Cloneable

Mermaid 类图：IdentityHashMap 继承体系

classDiagram
    class Map~K,V~ {
        <<interface>>
        size()
        isEmpty()
        containsKey(Object)
        containsValue(Object)
        get(Object)
        put(K, V)
        remove(Object)
        putAll(Map)
        clear()
        keySet()
        values()
        entrySet()
        equals(Object)
        hashCode()
    }
    class AbstractMap~K,V~ {
        <<abstract>>
        +AbstractMap()
        +size() int
        +isEmpty() boolean
        +containsValue(Object) boolean
        +containsKey(Object) boolean
        +get(Object) V
        +put(K, V) V
        +remove(Object) V
        +putAll(Map) void
        +clear() void
        +keySet() Set
        +values() Collection
        +entrySet() Set
        +equals(Object) boolean
        +hashCode() int
        +toString() String
        #clone() Object
    }
    class IdentityHashMap~K,V~ {
        -table : Object[]
        -size : int
        -modCount : int
        +IdentityHashMap()
        +IdentityHashMap(int expectedMaxSize)
        +IdentityHashMap(Map)
        +get(Object) V
        +put(K, V) V
        +remove(Object) V
        +containsKey(Object) boolean
        +containsValue(Object) boolean
        +clear() void
        +size() int
        +equals(Object) boolean
        +hashCode() int
        +clone() Object
    }
    AbstractMap ..|> Map
    IdentityHashMap --|> AbstractMap : 继承

图表说明：

• 一句话概括：IdentityHashMap 通过继承 AbstractMap 复用大部分 Map 操作的默认实现，仅重写了关键方法来贯彻其引用相等的语义。
• 逐层分解：
  • 第一层（接口定义）：Map 接口约定了基于 equals 和 hashCode 的通用规则。IdentityHashMap 虽然实现了 Map，但在 containsKey、containsValue、get、remove 等方法中明确使用了 == 而非 equals。
  • 第二层（抽象基类）：AbstractMap 提供了许多方法的默认实现，但它的 equals 方法是基于条目逐一 equals 比较的，这不符合 IdentityHashMap 的语义。因此，IdentityHashMap 必须重写 equals 方法并在文档中声明它故意破坏 Map 的契约。
  • 第三层（具体类特性）：IdentityHashMap 内部使用 Object[] table 作为唯一的数据容器，没有内部 Node 类。它的所有核心逻辑（哈希、索引、探测、增删改）都是自包含的。
• 关键结论强调：IdentityHashMap 是在实现 Map 接口的前提下，有选择地背离了接口的语义约定，这种背离是经过精心设计和文档声明的，并非缺陷。 理解这一点是掌握该类的关键。

---

Part 2：存储与构造篇

模块 3：存储结构与核心字段（源码剖析）

IdentityHashMap 的存储结构极其简练，它使用一个单一的 Object[] 数组分摊键和值，没有任何额外的节点包装类。

核心字段（摘取自 JDK 8 java.util.IdentityHashMap 源码）：

// 底层存储数组，容量始终为 2 的幂，最小 4
private transient Object[] table;

// 当前已存储的键值对数量（不是数组槽位占用数）
private transient int size;

// 结构修改次数，用于迭代器的快速失败检测
private transient int modCount;

// 默认初始容量（32），注意是容量，table 长度 = capacity * 2
private static final int DEFAULT_CAPACITY = 32;

// 实际最小容量
private static final int MINIMUM_CAPACITY = 4;

// 最大容量（2^29）
private static final int MAXIMUM_CAPACITY = 1 << 29;

// 阈值（threshold = capacity * 2/3），当 size >= threshold 时触发扩容
private transient int threshold; // 实际初始化后 threshold = (capacity - (capacity>>2))

// 用于缓存空键的不可变对象，仅用于迭代器，此处暂不深究
private static final Object NULL_KEY = ...;

底层数组布局详解：

table 数组的长度 L = capacity * 2，且 capacity 为 2 的幂。其中索引 i 满足：

• 偶数索引 (0, 2, 4, ... , L-2)：存储键对象 (key)。
• 奇数索引 (1, 3, 5, ... , L-1)：存储值对象 (value)。
• 空槽位：如果某个偶数索引处键为 null，表示该槽位未被占用或已删除，对应的奇数索引也会是 null（或保留旧值待清理）。

这种交替存储方式将键和值紧密耦合在一起，一次探测即可同时定位键槽和值槽，极大提高了缓存命中率。

Mermaid 类图：table 数组布局与线性探测机制

classDiagram
    class TableArray {
        <<array of Object>>
        index0 : key0
        index1 : value0
        index2 : key1
        index3 : value1
        index4 : null (empty)
        index5 : null (empty)
        index6 : key2 (collision)
        index7 : value2
        ...
    }
    class ProbeExample {
        +probe(int hash) : int
    }
    TableArray : + 哈希冲突后，线性探测下一个偶数索引 +2，直到找到空键槽
    TableArray : + 删除元素后，需要将后续冲突元素前移，防止断链
    ProbeExample : + linearProbe(startIndex) = (startIndex + 2) mod table.length

图表说明：

• 一句话概括：table 数组通过奇偶索引立体化存储键值对，线性探测则沿着偶数索引步进查找空槽。
• 逐层分解：
  • 第一层（结构映射）：数组索引 0 为第 0 个键，索引 1 为其对应的值；索引 2 为第 1 个键，索引 3 为其值。如果 key 为 null，则该槽位被视为空。
  • 第二层（冲突解决）：当基于哈希计算出的起始偶数索引已被占用且不是同一个键（!=）时，探测算法将索引每次增加 2 并取模，直到找到空槽或找到同一个键。
  • 第三层（删除影响）：删除一个元素不能简单地将键值置 null，因为这样会断开探测链，导致后续冲突的元素无法被查找到。IdentityHashMap 采用了重新插入（close_deletion）策略来维持探测链的连续性（详见模块 7）。
• 关键结论强调：双数组偶奇存储+线性探测，本质上是用空间连续性换取时间效率，且不需要额外的节点对象开销。

---

模块 4：构造方法

IdentityHashMap 提供了三个构造器，全部围绕确定一个 2 的幂的容量 展开。

构造器 1：无参构造 IdentityHashMap()

public IdentityHashMap() {
    init(DEFAULT_CAPACITY); // 32
}

构造器 2：指定期望最大映射数 IdentityHashMap(int expectedMaxSize)

public IdentityHashMap(int expectedMaxSize) {
    if (expectedMaxSize < 0)
        throw new IllegalArgumentException("expectedMaxSize is negative: " + expectedMaxSize);
    init(capacity(expectedMaxSize));
}

// 根据期望大小计算大于等于它的最小 2 的幂（且 >= 4）
private static int capacity(int expectedMaxSize) {
    // 加上三分之一，以满足负载因子 2/3 的要求
    int minCapacity = expectedMaxSize + (expectedMaxSize / 3);
    // 返回大于等于 minCapacity 的最小 2 的幂
    return Integer.highestOneBit((minCapacity - 1) << 1);
}

构造器 3：从其他 Map 构造 IdentityHashMap(Map<? extends K, ? extends V> m)

public IdentityHashMap(Map<? extends K, ? extends V> m) {
    this((int)((1 + m.size()) * 1.1)); // 估算容量
    putAll(m);
}

putAll 会调用 put，此时键的比较将基于 == 而非 equals。如果原 Map 中有多个 equals 相等但 == 不同的键，它们将被视为不同键，都会被插入。但如果原 Map 中的某些键在 == 意义下相同（例如同一个 String 对象被多次添加），新的 IdentityHashMap 只会保留一次（因为 put 会覆盖值）。

---

Part 3：核心原理篇

模块 5：哈希计算与索引定位（源码剖析）

哈希与索引定位是开放寻址性能的关键。IdentityHashMap 刻意绕开了对象自身的 hashCode()，使用 System.identityHashCode。

源码分析（IdentityHashMap 内部方法）：

// 计算对象的身份哈希，对 null 返回 0
private static int hash(Object x, int length) {
    int h = System.identityHashCode(x);
    // 高16位与低16位异或，减少高位丢失，类似于 HashMap 的扰动函数
    h = h ^ (h >>> 16);
    // 确保索引是偶数，并且落在表范围内
    return (h & (length - 1)) << 1; // 注意 length 是 capacity * 2
}

关键点：

• System.identityHashCode(x) 是一个 native 方法，通常返回对象在内存中的原始哈希值（由对象头或内存地址生成），它不受任何 hashCode() 重写影响。这保证了即使对象是可变且重写了 hashCode，其身份哈希依然稳定。
• 扰动函数 h ^ (h >>> 16) 让高位影响低位，使哈希分布更均匀。
• 最终索引 (h & (length - 1)) << 1 保证了结果始终是偶数（最低位为 0），从而准确落到键槽上。

Mermaid 流程图：哈希计算与索引定位

flowchart TD
    A["输入 key 和 table.length"] --> B{"key == null?"}
    B -- 是 --> C["h = 0"]
    B -- 否 --> D["h = System.identityHashCode(key)"]
    C --> E["hash = h ^ (h >>> 16)"]
    D --> E
    E --> F["index = (hash & (length - 1)) << 1"]
    F --> G["返回偶数索引（键槽位置）"]

图表说明：

• 一句话概括：该流程从对象身份哈希值出发，经过扰动和掩码运算，最终生成一个仅落在偶数位上的数组索引。
• 逐层分解：
  • 第一层（哈希源）：优先处理 null 键，哈希值固定为 0，避免空指针。对于非 null 键，调用 System.identityHashCode 获取原始哈希。
  • 第二层（扰动优化）：将高 16 位与低 16 位异或，增加低位随机性，降低直接取模带来的冲突概率。
  • 第三层（索引定位）：通过 (length - 1) 取模，并左移一位（即乘以 2）确保索引为偶数，直接指向键槽。
• 源码方法对应：完全对应 IdentityHashMap 的 private static int hash(Object x, int length) 方法。
• 关键结论强调：使用 System.identityHashCode 是 IdentityHashMap 区别于所有内容敏感 Map 的根基，它赋予了映射“对象身份”的稳定性。

---

模块 6：put 操作——线性探测插入（源码剖析）

put(K key, V value) 是 IdentityHashMap 最核心的修改方法。其流程完整诠释了线性探测在双数组中的工作方式。

简化源码（JDK 8）：

public V put(K key, V value) {
    final Object[] tab = table;
    final int len = tab.length;
    int i = hash(key, len); // 起始偶数索引

    // 线性探测：遍历键槽
    Object item;
    while ((item = tab[i]) != null) {
        if (item == key) { // 引用相等判断
            // 键已存在，替换值
            @SuppressWarnings("unchecked")
            V oldValue = (V) tab[i + 1];
            tab[i + 1] = value;
            return oldValue;
        }
        i = nextKeyIndex(i, len); // 索引 +2，若越界则回到 0
    }

    // 找到空槽位，插入新条目
    tab[i] = key;
    tab[i + 1] = value;
    size++;
    modCount++;

    // 检查是否需要扩容
    if (size >= threshold)
        resize(len * 2); // len = table.length，扩容为 2 倍
    return null;
}

private static int nextKeyIndex(int i, int len) {
    return (i + 2 < len) ? i + 2 : 0;
}

流程说明：

1. 计算起始索引 i。
2. 进入 while 循环，检查 tab[i] 是否为 null。如果不是 null，则通过 == 与传入的 key 比较。
3. 如果 == 成立，说明已经存在该键的映射，直接替换奇数索引处的值，并返回旧值。
4. 如果 !=, 则调用 nextKeyIndex 前进到下一个偶数索引，继续探测。
5. 如果退出循环（遇到空槽），意味着该键尚不存在。将键放入 tab[i]，值放入 tab[i+1]，增加 size，并检查扩容。

删除元素后的影响：注意，这里插入时遇到 tab[i] == null 就直接占用，而不是去寻找“被删除”的标记。因为 IdentityHashMap 的删除操作不会留下持久空槽，它会采用重哈希的方式清理探测链，保证了空槽真的意味着“未使用”。

Mermaid 流程图：put 操作的线性探测流程

flowchart TD
    Start["put(key, value)"] --> Hash["i = hash(key, table.length)"]
    Hash --> CheckNull{"tab[i] == null?"}
    CheckNull -- 是 --> Insert["tab[i] = key<br/>tab[i+1] = value<br/>size++"]
    CheckNull -- 否 --> CompareEQ{"tab[i] == key ?"}
    CompareEQ -- 是 --> Replace["oldVal = tab[i+1]<br/>tab[i+1] = value<br/>return oldVal"]
    CompareEQ -- 否 --> NextIdx["i = nextKeyIndex(i, len) 即 +2 模长"]
    NextIdx --> CheckNull
    Insert --> CheckResize{"size >= threshold ?"}
    CheckResize -- 是 --> Resize["resize(len*2)"]
    CheckResize -- 否 --> ReturnNull["return null"]
    Resize --> ReturnNull

图表说明：

• 一句话概括：put 通过线性探测查找键槽，找到了相同引用则替换，否则占领第一个空槽，并在必要时触发扩容。
• 逐层分解：
  • 第一层（入口与哈希）：从哈希计算得到起始偶数索引，这是 O(1) 操作。
  • 第二层（探测循环）：使用 while 循环遍历键槽数组，每次比较仅基于 ==，这是引用相等语义的集中体现。
  • 第三层（命中与更新）：若对比成功，直接修改奇数索引的值，保证了值的即时更新。
  • 第四层（未命中插入）：遇到 null 槽表示探测链结束，直接将键值插入当前槽，然后检查扩容。这种设计保证了空槽就是可以安全占用的。
• 源码方法对应：put(K, V) 及私有的 nextKeyIndex(int, int)。
• 关键结论强调：IdentityHashMap 的 put 不会碰到“已删除但标记为可用”的槽位，因为它的 remove 会彻底整顿探测链（见模块 7）。这使得插入逻辑异常简洁。

---

模块 7：remove 操作——线性探测的“滞后清除”

在开放寻址法中，删除元素不能仅仅将槽位置为 null，否则会切断探测链，导致后续可能发生冲突的元素永久无法查找到。IdentityHashMap 的 remove 实现采用了**“重新插入”**策略（close_deletion），来保证探测链的连续性。

源码参考（JDK 8 remove(Object key) 内部核心逻辑）：

public V remove(Object key) {
    Object[] tab = table;
    int len = tab.length;
    int i = hash(key, len);

    // 寻找要删除的键
    while (true) {
        Object item = tab[i];
        if (item == key) {
            // 找到目标，记录旧值并开始删除-重构过程
            @SuppressWarnings("unchecked")
            V oldValue = (V) tab[i + 1];
            tab[i] = null;    // 清空键槽
            tab[i + 1] = null; // 清空值槽
            size--;
            modCount++;
            closeDeletion(i, tab, len); // 重整后续元素
            return oldValue;
        }
        if (item == null) {
            // 探测结束，未找到
            return null;
        }
        i = nextKeyIndex(i, len);
    }
}

核心：closeDeletion 方法（简化逻辑）

private void closeDeletion(int d, Object[] tab, int len) {
    // 从被删除槽的下一个键槽开始，直到遇到空槽为止
    for (int i = nextKeyIndex(d, len); (item = tab[i]) != null; i = nextKeyIndex(i, len)) {
        // 检查当前元素是否处于“原本应该待的位置”之前
        int r = hash(item, len);
        // 如果当前元素的理想位置在删除槽 d 和当前位置 i 之间（环形包裹），
        // 则它可能因为之前的冲突被推到更远，现在需要前移。
        if ((i < d && (r <= i || r > d)) || (i > d && (r <= i && r > d))) {
            // 确实需要前移：将该键值对复制到 d 位置
            tab[d] = item;
            tab[d + 1] = tab[i + 1];
            // 清空旧位置
            tab[i] = null;
            tab[i + 1] = null;
            d = i; // 更新当前空洞位置，继续处理后续
        }
    }
}

文字解释“滞后清除”过程：

1. 找到要删除的键 K 的槽位 d，将其键值置为 null。
2. 从 d 的下一个键槽开始遍历，直到遇到 null（即探测链结束）。
3. 对于链上的每个元素 E，判断它的理想哈希位置是否在 d 和它的当前位置之间（循环意义下）。如果是，说明 E 当初是因为冲突被挤到这里的，现在 d 已经成为空槽，E 理应被“拉”到 d 或更靠前的位置。
4. 将 E 复制到空洞 d 处，并将 E 原来的位置变为新的空洞，继续向后查找。
5. 最终，空洞会被推至探测链的末尾，探测链中的所有元素都连续排列在它们理想位置或紧邻之后。

Mermaid 流程图：删除后重组探测链（closeDeletion）

flowchart TD
    Start["remove(key) 定位到删除槽 d"] --> MarkNull["tab[d]=null, tab[d+1]=null<br/>size--, 记录空洞 d"]
    MarkNull --> Init["i = nextKeyIndex(d, len)<br/>开始扫描后续元素"]
    Init --> CheckNull{"tab[i] == null ?"}
    CheckNull -- 是 --> End["重组完成，返回"]
    CheckNull -- 否 --> CalcHash["计算当前元素 item 的理想位置 r = hash(item, len)"]
    CalcHash --> NeedMove{"item 需要前移到空洞 d 吗？<br/>（根据环形条件判断）"}
    NeedMove -- 是 --> Move["tab[d]=item, tab[d+1]=val<br/>清空旧位置 i<br/>d = i (空洞后移)"]
    NeedMove -- 否 --> NextIdx["i = nextKeyIndex(i, len)"]
    Move --> NextIdx
    NextIdx --> CheckNull

图表说明：

• 一句话概括：closeDeletion 通过将探测链上原本被迫后移的元素向空洞前移，保持探测链连续紧凑，杜绝“假空槽”。
• 逐层分解：
  • 第一层（空洞产生）：删除操作首先将目标槽清空，形成空洞 d。
  • 第二层（扫描后续）：从 d 的下一个槽开始，遍历整个连续段（直到遇见 null）。
  • 第三层（前移条件判断）：核心逻辑是根据元素理想位置 r 和当前空洞 d、当前位置 i 的环状关系，判断该元素是否本应占据更靠前的位置。这类似于Linux 内核中的红黑树删除重平衡，都是为了保持数据结构的性质。
  • 第四层（空洞传递）：每次移动都将空洞向探测链尾部传递，最终空洞落入一个原本就是 null 的边缘，循环结束。
• 源码方法对应：remove(Object) 和 private void closeDeletion(int d, Object[] tab, int len)。
• 关键结论强调：IdentityHashMap 的删除不是简单置空，而是执行了探测链压缩，这使得空槽永远代表“未使用”，插入无须处理特殊标记，极大地简化了 put/get 逻辑。这种以删改代价换取查找无副作用的策略，非常适合频繁读写的场景。**

---

模块 8：get 与 containsKey/Value

get 方法基于线性探测查找，完全依赖 ==：

public V get(Object key) {
    Object[] tab = table;
    int len = tab.length;
    int i = hash(key, len);
    while (true) {
        Object item = tab[i];
        if (item == key) // 引用相等找到
            return (V) tab[i + 1];
        if (item == null) // 没找到
            return null;
        i = nextKeyIndex(i, len);
    }
}

containsKey 与 get 几乎一致，只是返回 boolean。

containsValue 由于值槽没有哈希索引，只能线性遍历整个数组的所有奇数索引：

public boolean containsValue(Object value) {
    Object[] tab = table;
    for (int i = 1; i < tab.length; i += 2) { // 只检查值槽
        if (tab[i] == value && tab[i - 1] != null) // 值匹配且键非 null 才有效条目
            return true;
    }
    return false;
}

注意值比较也使用 ==！如果希望基于 equals 匹配值，该方法无法满足，这正是特化语义的一部分。

---

模块 9：扩容机制

当 size >= threshold 时，put 会触发 resize。扩容过程新建一个 2 倍长度的数组（最小保证 capacity 为 2 的幂），然后重新哈希并插入所有现有的条目。

源码关键路径：

private void resize(int newCapacity) {
    int newLength = newCapacity * 2; // table 新长度
    Object[] oldTable = table;
    int oldLength = oldTable.length;
    if (oldLength == MAXIMUM_CAPACITY * 2) {
        // 达到最大容量，仅提升阈值防止继续扩容
        if (size >= MAXIMUM_CAPACITY - 1)
            throw new IllegalStateException("Capacity exhausted.");
        threshold = Integer.MAX_VALUE;
        return;
    }
    Object[] newTable = new Object[newLength];
    // 遍历旧表每条记录
    for (int i = 0; i < oldLength; i += 2) {
        Object key = oldTable[i];
        if (key != null) {
            Object value = oldTable[i + 1];
            // 重新计算哈希并线性探测插入新表
            int idx = hash(key, newLength);
            while (newTable[idx] != null)
                idx = nextKeyIndex(idx, newLength);
            newTable[idx] = key;
            newTable[idx + 1] = value;
        }
    }
    table = newTable;
    threshold = newCapacity - (newCapacity >> 2); // 2/3 阈值
}

扩容后，原来因冲突而分散的条目在新表中可能聚集到更理想的位置，相当于一次全量整理，能显著改善探测性能。

---

Part 4：特性与约束篇

模块 10：违背 Map 契约的设计意图

IdentityHashMap 的 JavaDoc 开头就明确写道：

This class implements the Map interface with a hash table, using reference-equality in place of object-equality when comparing keys (and values). In other words, in an IdentityHashMap, two keys k1 and k2 are considered equal if and only if (k1 == k2). (In normal Map implementations (like HashMap) two keys k1 and k2 are considered equal if and only if (k1 == null ? k2 == null : k1.equals(k2)).)

This class is not a general-purpose Map implementation! While this class implements the Map interface, it intentionally violates Map's general contract, which mandates the use of the equals method when comparing objects. This class is designed for use only in the rare cases wherein reference-equality semantics are required.

设计意图分析：

• Map 契约要求 containsKey、get 等方法使用 equals 比较键，但 IdentityHashMap 故意使用 ==。这导致如果一个 HashMap 和一个 IdentityHashMap 互相调用 equals 方法，可能得不到预期的对称结果。
• 同样，IdentityHashMap 的 hashCode 方法也不遵循 Map 接口要求的“每个条目的哈希值求和”规则，而是基于 System.identityHashCode 组合计算。
• 这种“明知故犯”是为了服务于 Java 生态中少数但关键的对象身份敏感场景，如序列化、反射、动态代理等，这些场景要求严格区分不同实例。

Mermaid 流程图：违背契约的设计哲学

flowchart TD
    MapContract["Map 通用契约<br/>规定 equals 比较键"] --> GeneralMap["实现类如 HashMap<br/>严格遵循"]
    MapContract --> IDHM["IdentityHashMap<br/>故意违反：使用 =="]
    IDHM --> Reason["原因：对象身份语义<br/>（序列化循环跟踪、Class缓存等）"]
    Reason --> TradeOff["权衡：牺牲通用性，换取特定场景 正确性 + 性能"]
    TradeOff --> Doc["文档明确声明<br/>非通用 Map<br/>不适用于常规映射"]

图表说明：

• 一句话概括：IdentityHashMap 对 Map 契约的违背是有意为之，以换取对象身份敏感场景下的正确性和紧凑实现。
• 逐层分解：
  • 第一层（契约分歧）：Map 接口要求基于 equals，IdentityHashMap 却使用 ==，这是根本性的语义分歧。
  • 第二层（存在理由）：这种分歧源自真实需求——序列化引擎必须区分相同内容的不同对象实例，否则循环引用处理将出错。
  • 第三层（风险控制）：JDK 通过文档明确告知这不是通用 Map，让使用者在享受特定好处的同时，清醒认识到混用可能带来的问题。
• 关键结论强调：故意违反契约不是设计缺陷，而是特定领域需求驱动下的合理取舍，前提是必须清晰隔离并文档化。

---

模块 11：与 HashMap 的精细对比

IdentityHashMap 与 HashMap 分别代表了 Map 家族的两种极端：引用身份敏感 与 内容相等敏感。它们的差异深入到语义、存储、性能等每个层面。

全方位对比表：

对比维度	IdentityHashMap	HashMap
键相等判定	== （引用相等）	equals （内容相等）
哈希计算来源	System.identityHashCode(x) （不变）	key.hashCode() （可能被重写）
存储结构	单个 Object[] 双数组 + 线性探测	Node<K,V>[] 链表/红黑树 + 拉链法
负载因子	固定 2/3 （近似 0.67）	可自定义，默认 0.75
内存开销	无额外节点对象，键值紧邻，开销小	每个条目有 Node 对象头 + 引用字段，开销大
并发	非线程安全，结构修改 CME	非线程安全，结构修改 CME
null 键	允许，哈希为 0，唯一	允许，哈希为 0，唯一
扩容	2 倍数组，rehash	2 倍数组，rehash（树可能拆分）
迭代顺序	完全不确定，与探测链相关	桶顺序，不确定
containsValue	使用 ==	使用 equals

Mermaid 流程图：HashMap 与 IdentityHashMap 决策路径对比

flowchart TD
    subgraph HashMap_Path ["HashMap 路径：内容相等"]
        HK["键 K1, K2"] --> Hash1["hash = (key == null) ? 0 : h = key.hashCode() ^ (h >>> 16)"]
        Hash1 --> Eq1{"key1.equals(key2) ?"}
        Eq1 -- 是 --> SameSlotHM["视为相同键"]
        Eq1 -- 否 --> DiffSlotHM["视为不同键"]
    end

    subgraph IdentityHashMap_Path ["IdentityHashMap 路径：引用相等"]
        IK["键 K1, K2"] --> Hash2["hash = System.identityHashCode(key) ^ (>>>16)"]
        Hash2 --> Eq2{"key1 == key2 ?"}
        Eq2 -- 是 --> SameSlotID["视为相同键"]
        Eq2 -- 否 --> DiffSlotID["视为不同键"]
    end

    Choice{"需求：区分不同实例？"}
    Choice -- 需要区分实例 --> IdentityHashMap_Path
    Choice -- 只需比较内容 --> HashMap_Path

图表说明：

• 一句话概括：两条路径的根本分歧在于比较操作符（== vs equals） 和哈希生成方式，这决定了它们适用完全不同的业务需求。
• 逐层分解：
  • 第一层（实例 vs 内容）：IdentityHashMap 关注“这是否是同一个对象”，而 HashMap 关注“它们的内容是否相等”。同一个文件读取出的两个相同内容的 String 对象，在 IdentityHashMap 中会被视为两个不同的键。
  • 第二层（哈希依赖）：IdentityHashMap 的哈希不受 hashCode() 重写影响，即使一个类的 hashCode 返回常量，identityHashCode 依然分布良好；而 HashMap 严重依赖 hashCode() 的散列质量。
  • 第三层（性能特征）：小规模下 IdentityHashMap 因无节点开销而更省内存；但随着冲突增多，线性探测可能导致多次缓存缺失，性能退化为 O(n)。HashMap 则借助树化（Java 8+）缓解了浓度问题。
• 关键结论强调：绝对不可以用 IdentityHashMap 代替 HashMap 来处理常规业务逻辑，这是最常见的误用陷阱。

---

Part 5：陷阱与实践篇

模块 12：常见陷阱与最佳实践

陷阱 1：相同内容的不同对象被视为不同键

IdentityHashMap<String, String> map = new IdentityHashMap<>();
map.put(new String("key"), "value1");
map.put(new String("key"), "value2");
System.out.println(map.size()); // 输出 2，而非 1

因为 new String("key") 创建了两个不同实例，== 比较为 false。大多数开发者预期的大小为 1，这里出现了认知偏差。

陷阱 2：String 字面量与 intern 的混乱

String a = "key";
String b = new String("key");
IdentityHashMap<String, String> map = new IdentityHashMap<>();
map.put(a, "value1");
map.put(b, "value2");
System.out.println(map.size()); // 2
map.put(b.intern(), "value3");  // intern 返回常量池中的 "key"，即 a
System.out.println(map.size()); // 还是 2，但 a 对应的值被更新为 "value3"

由于 intern() 的存在，原本通过引用相等就不匹配的两个键可能突然发生碰撞，需要警醒。

陷阱 3：值比较也使用 ==

containsValue 和值替换都是用 == 比较，如果你依赖 equals 匹配值，可能会找不到预期的值。

陷阱 4：迭代时结构修改抛出 CME

和大多数集合一样，IdentityHashMap 的迭代器是快速失败的。如果在迭代过程中使用非迭代器方法（如 put、remove）修改映射，会立即触发 ConcurrentModificationException。

最佳实践：

• 仅在明确需要对象身份跟踪时使用。例如构建一个对象到锁的映射 IdentityHashMap<Object, Lock>，确保每个对象的锁唯一。
• 结合 Collections.newSetFromMap 创建基于身份的 Set：Set<Foo> set = Collections.newSetFromMap(new IdentityHashMap<>()); 可以方便地实现基于引用相等的集合，用于对象去重。
• 在序列化/反序列化中，使用 IdentityHashMap 作为已处理对象的记录表，防止重复处理或无限循环。
• 注意对象生命周期：如果你用 IdentityHashMap 缓存计算结果，键对象如果不再被外部引用，将无法被 GC 回收（因为是强引用）。可以考虑配合 WeakHashMap 或 SoftReference 使用，但那样会失去引用相等语义。通常 IdentityHashMap 用于短期、请求级缓存。

---

Part 6：总结与面试篇

模块 13：性能总结

• 时间复杂度：
  • get、put、remove：平均 O(1)，但在高负载、大量冲突时探测路径变长，退化为 O(n)。
  • containsValue：O(n)，需要遍历整个值槽。
• 空间效率：由于没有 Node 对象头（每个 HashMap 的 Node 约占用 24-32 字节，取决于 JVM），IdentityHashMap 在存储大量小键值对时内存优势显著。但其数组利用率并不高：负载因子固定 2/3，意味着数组总有约 1/3 的槽位为空。
• 适用密度：小巧精悍的映射、键对象本身轻量（如 Class 实例），是它的甜区。键对象过于庞大且数量多时，线性探测的缓存未命中代价不可忽视。

模块 14：面试高频专题

---

问题 1：IdentityHashMap 和 HashMap 的区别？为什么要故意违背 Map 的约定？

• 标准回答：IdentityHashMap 使用 ==（引用相等）比较键和值，以 System.identityHashCode 计算哈希；而 HashMap 使用 equals 和 hashCode 方法。IdentityHashMap 故意违背 Map 契约是为了满足某些需要精确区分对象身份的专用场景（如序列化防止循环引用、JVM 内部缓存），在这些场景中，两个内容相同的不同对象必须被当作不同的键处理。
• 追问模拟：既然它违背了契约，为什么还要实现 Map 接口？这不是破坏了多态吗？
• 加分回答：这正是它设计上的“任性”之处。它实现了 Map 接口是为了融入集合框架，可以使用 Collections 工具类（如 newSetFromMap）以及被序列化引擎等内部代码以统一接口操作。但它通过文档严正声明这不是通用 Map，任何将其作为 Map 传入公共方法的行为都属非法，因此这个违背是受控的、针对内部使用的。
• 进一步加分：实际上 JDK 中不止 IdentityHashMap 违背契约，enum maps 的某些行为也略有差异，但 IdentityHashMap 最为典型。

---

问题 2：IdentityHashMap 是如何比较键的？用什么代替 equals？

• 标准回答：它直接用引用比较操作符 == 来比较键和值。在 put、get、remove、containsKey 等关键方法中，判断 item == key 而不是 item.equals(key)。
• 追问模拟：如果我想让一个对象序列化时使用 IdentityHashMap 的内部跟踪，但我的对象的 equals 和 hashCode 写得不好会有影响吗？
• 加分回答：完全没影响。因为 IdentityHashMap 完全不调用 equals 和 hashCode，它依赖 JVM 赋予的对象身份特征，这正是它的隔离性优势。

---

问题 3：什么是开放寻址法？IdentityHashMap 如何解决哈希冲突？

• 标准回答：开放寻址法是一种将所有元素都存储在哈希表数组本身的方法，不借助额外的链表。IdentityHashMap 使用线性探测：当哈希索引的键槽已被占用时，检查下一个偶数索引（i+2），直到找到空槽或找到引用相等的键。
• 追问模拟：线性探测有什么缺点？IdentityHashMap 有做优化吗？
• 加分回答：线性探测容易造成集群现象（primary clustering），即连续占用导致后续探测变长。IdentityHashMap 通过两个方式缓解：扰动函数 h ^ (h >>> 16) 使分布更均匀，以及采用 2/3 的负载因子（比 HashMap 的 0.75 略低），保留更多空闲槽位减少冲突。此外，扩容时重建表也是一次整理。

---

问题 4：IdentityHashMap 的底层数组是如何布局的？为什么用偶数索引存 key？

• 标准回答：使用单个 Object[] table，偶数索引（0,2,4...）存放 key，奇数索引（1,3,5...）存放 value。偶数索引存 key 是因为索引计算公式 (hash & (len-1)) << 1 直接得出 key 的槽位，value 紧随其后，一步定位。
• 追问模拟：使用两个独立数组（一个存 key，一个存 value）不是更简单吗？
• 加分回答：单数组交替存储提高了缓存局部性。键和值往往一起被访问，在内存中相邻放置，能利用 CPU 缓存行，减少 cache miss。同时，这样避免了两个数组的额外对象引用。

---

问题 5：System.identityHashCode 是什么？和 Object.hashCode 有何区别？

• 标准回答：System.identityHashCode(x) 是一个本地方法，返回 JVM 为对象 x 生成的“原始”哈希码，通常基于内存地址或内部标识，不受对象 hashCode() 方法重写的影响。而 Object.hashCode() 可以被重写，返回开发者希望的哈希值。
• 追问模拟：如果一个类故意让 hashCode 返回常数，那么 identityHashCode 也会返回常数吗？
• 加分回答：不会。identityHashCode 相当于绕过了所有的重写，直接读取对象的原始身份标识，确保分布良好，这对 IdentityHashMap 至关重要。
• 进一步加分：在 HotSpot JVM 中，identityHashCode 的生成方式与偏向锁、对象头中的 hash 字段有关，一旦生成就可能被缓存在对象头中以保证稳定。

---

问题 6：IdentityHashMap 的扩容和负载因子是多少？为什么默认容量是 32？

• 标准回答：负载因子固定为 2/3（即阈值 threshold = capacity * 2/3）。默认构造时 capacity 为 32，table 长度为 64。扩容时容量和 table 长度都翻倍。
• 追问模拟：为什么默认是 32，而不是 HashMap 的 16？
• 加分回答：IdentityHashMap 的 table 长度是 2 * capacity，它每个槽位没有链表，因此需要预留更多空间来直接存储键值对。假如预期存储 10 个元素，HashMap 初始 16 槽位 + 链表也可以应付，但 IdentityHashMap 需要足够的连续空槽来保证探测效率。32 容量 (64 长度) 是一个经验值，能让小映射的性能表现良好。而且构造器 IdentityHashMap(int expectedMaxSize) 会根据期望大小自动计算合适的 2 的幂容量，对调用者透明。

---

问题 7：如何用 IdentityHashMap 实现一个基于对象身份的 Set？

• 标准回答：Set<Foo> idSet = Collections.newSetFromMap(new IdentityHashMap<>()); 这会返回一个内部使用 IdentityHashMap 的 Set，所有 add、contains 等操作都基于引用相等。
• 追问模拟：这样做有什么好处？
• 加分回答：可以用作对象身份的去重容器，比如记录已访问的节点实例（而不是节点值），在图形算法中防止同一实例进入集合两次，即使内容相同。

---

问题 8：为什么不能在普通业务代码中用 IdentityHashMap 替代 HashMap？

• 标准回答：因为普通业务通常基于内容相等来查找数据，比如根据用户名查找用户对象。IdentityHashMap 只认对象引用，会导致相同内容的两个不同 String 被视为不同 key，造成数据错乱、查找失败。
• 追问模拟：如果我在业务中使用了常量池字符串，是不是就没事？
• 加分回答：非常危险。即使短时间内因为字符串驻留而碰巧工作，但一旦数据来自用户输入、数据库读取等，就会产生不同实例，造成难以排查的 bug。绝对禁止。

---

问题 9：举出 IdentityHashMap 在 JDK 内部的一个典型应用？

• 标准回答：一个典型应用是 java.io.ObjectOutputStream 的序列化过程。它使用 IdentityHashMap 记录已序列化的对象，以此检测循环引用：当第二次遇到同一个对象实例时，不会再次递归序列化，而是写入一个反向引用句柄。
• 追问模拟：为什么不用 HashMap 结合 System.identityHashCode 和一个包装类实现？
• 加分回答：那样做会引入额外的包装对象（类似 Entry），增加内存开销，并且两次哈希查找（一次 identityHashCode，一次 equals）也会性能更差。IdentityHashMap 直接在双数组中完成一切，且语义明确，是内置最理想方案。
• 进一步加分：ThreadLocal.ThreadLocalMap 实际上采用了非常类似的设计，用开放寻址线性探测和 identityHashCode（针对线程对象），只是它没有直接使用 IdentityHashMap 而是独立实现。

---

问题 10：在什么场景下 IdentityHashMap 比 HashMap 更合适？

• 标准回答：需要把对象实例本身作为唯一标识的场景，例如：对象元数据缓存（每个实例有自己的锁、状态）、防止重复处理同一个实例的访问跟踪、基于实例的监听器列表等。
• 追问模拟：能举个具体的例子吗？
• 加分回答：假设你正在实现一个内存数据库的事务层，需要跟踪哪些实体对象被修改了。使用 IdentityHashMap<Entity, Object> 记录已被脏标记的实例，这样即使两个实体数据内容完全相同，只要它们是内存中不同的对象，就会被正确标记。如果用 HashMap，两个内容相同的对象会被误判为同一个，导致事务不正确。