IdentityHashMap通过引用相等（==）和System.identityHashCode()精准区分不同异常实例，避免HashMap因equals()误合并；适用于异常聚合分析等需引用级识别的场景。
IdentityHashMap 在处理异常对象时，能基于引用相等性（==）精准区分“内容相同但实例不同”的异常，从而避免传统 Map 因 equals() 导致的误合并。这不是“绕过去重”，而是按需选择更严格的去重语义。
为什么异常对象容易被 HashMap 误判为重复
很多异常类（如 IllegalArgumentException、NullPointerException）未重写 equals() 方法，继承自 Object 的默认实现——即实际仍依赖引用相等。但一旦子类重写了 equals()（例如某些框架封装的业务异常），或异常携带了可序列化的上下文字段并参与比较，就可能出现多个独立抛出的异常实例因内容相似而被 HashMap 当作同一 key 覆盖。
典型场景包括：
- 统一异常捕获器中批量收集运行时异常用于聚合分析
- 测试框架中记录每次断言失败生成的
AssertionError实例 - 监控系统对同一类错误反复触发的异常做引用级归因（例如是否总来自同一个代理对象）
IdentityHashMap 如何确保异常实例不被意外覆盖
它用 System.identityHashCode() 计算哈希，用 == 判断键是否相等。这意味着：
- 即使两个
RuntimeException构造参数完全一致（如都传"timeout"），只要不是同一个对象实例，就视为不同 key - 对
null异常值也安全支持（IdentityHashMap明确允许null键和值） - 不会受异常类是否重写
equals()或hashCode()影响，行为稳定可预测
实用代码模式：按异常引用聚合堆栈或计数
例如，在诊断工具中统计**每个异常实例**的传播路径：
Map<Throwable, List<StackTraceElement[]>> traceMap = new IdentityHashMap<>();
// 每次捕获异常时：
try {
riskyOperation();
} catch (Throwable t) {
traceMap.computeIfAbsent(t, k -> new ArrayList<>()).add(t.getStackTrace());
}
这里若改用 HashMap，当两次抛出内容相同的 IOException（比如都带 message "Connection refused"），就可能只保留最后一次的堆栈，丢失关键时间线索。
注意事项与边界情况
需明确其设计定位：
- 不是通用替代品：它有意违反 Map 规范，不适用于需要逻辑等价性（如按错误码归类）的场景
- 不解决内存泄漏：若长期持有异常引用（尤其含大堆栈或上下文对象），需配合弱引用或手动清理
- 线程不安全：高并发下需外层同步，或包装为
Collections.synchronizedMap(new IdentityHashMap()) - 无法用于跨 JVM 或序列化场景：引用相等性在反序列化后必然失效
