IdentityHashMap的核心用途是基于引用相等（==）而非内容相等（equals）判断键唯一性，适用于需区分对象身份的场景，如对象图遍历防循环引用、AST节点状态标记、Class/Thread等单例对象映射、调试追踪对象实例路径，以及绕过不可修改类的equals语义；不适用于String、DTO等依赖值语义的类型，也非HashMap的纠错替代品。
IdentityHashMap 的核心用途，就是把“变量是否指向同一个对象”这件事，直接变成键的判定标准。它不看内容、不调用 equals()，只认内存地址——也就是 == 的结果。这种能力在常规业务逻辑里很少见，但在底层机制、调试辅助和对象生命周期管理中，恰恰不可替代。
需要区分对象身份而非内容的场景
当你关心“是不是这个对象”，而不是“是不是有相同值的对象”时，IdentityHashMap 就派上用场了。
- 缓存某个特定对象的临时元数据，比如给一个正在处理的 AST 节点挂一个解析状态标记，不同节点即使内容一样也不能共享状态
- 序列化/反序列化过程中记录已访问对象，防止循环引用导致栈溢出——必须按引用判断，否则两个内容相同的对象会被误判为“已处理过”
- JVM 层工具（如某些代理框架或关闭钩子注册表）用 Class、Thread、ClassLoader 这类天然单例性强的对象作 key，天然适合 == 判等
绕过 equals() 行为干扰的情况
有些类你无法修改，或者它的 equals() 语义和你当前需求冲突，这时候 IdentityHashMap 提供了一种“不改代码也能隔离语义”的轻量方案。
- 第三方库中的 final 类，重写不了 equals()，但你需要以实例为单位做映射
- DTO 或集合类被当作 key 使用，而它们的 equals() 基于字段比较，会导致意外覆盖；用 IdentityHashMap 就能保留每个实例的独立条目
- 调试时追踪对象创建路径：比如想确认某次反射 new 出来的对象和 JSON 反序列化出来的对象是不是同一个实例，直接 put 进去再 get 就能验证
null key 的精细控制能力
IdentityHashMap 对 null 的处理是基于引用的，这意味着它可以区分“不同来源的 null”——虽然实际开发中较少见，但在某些边界逻辑里很关键。
- map.put(null, "first") 和 map.put(null, "second") 在 IdentityHashMap 中会保留两条记录（size 为 2），因为每次传入的 null 是不同引用（比如来自不同方法的返回值）
- 而 HashMap 把所有 null 当作同一个 key，第二次 put 会覆盖第一次
- 注意：这不意味着鼓励滥用多个 null key，而是说明它在语义上更“透明”，不会隐藏引用差异
不适合用 IdentityHashMap 的典型误用
它不是 HashMap 的“补丁版”，也不是解决 equals 写错的捷径。
- 用 String 字面量（如 "abc"）当 key 时，由于字符串常量池复用地址，put("a", 1) 和 put("a", 2) 仍会覆盖——这不是 bug，是 JVM 特性，但容易让人误解
- 拿 Integer、Boolean 等包装类当 key 要小心自动装箱缓存（-128~127），范围内的值可能意外复用同一对象，破坏预期的“实例唯一性”
- 把可变对象（如 ArrayList）当 key 后又修改其内容，虽然 IdentityHashMap 还能查到，但业务逻辑上 key 已经“变质”，这种用法掩盖了设计问题
