Spring框架中ClassUtils的primitiveWrapperTypeMap为何用IdentityHashMap而非HashMap？

你提到的没错——Class<T>对象在JVM里是单例，它的equals()方法本质就是用==比较对象身份，用HashMap确实不会出现键冲突。选择IdentityHashMap主要有这几个原因：

• 微性能优化：IdentityHashMap的底层实现跳过了hashCode()计算和equals()方法调用，直接用对象的内存地址作为哈希值，用==做键匹配。对于Class这种天生单例的键来说，完全不需要额外的equals逻辑，用它能省掉一层方法调用的开销，在高频访问的场景下能带来微小但稳定的性能提升。

• 语义更精准：IdentityHashMap的设计初衷就是基于对象身份而非equals逻辑做键匹配。虽然Class的equals和==效果一致，但用IdentityHashMap相当于给阅读代码的人明确传递一个信号：这里的键匹配是严格的“同一个对象”比对，不存在任何自定义equals的特殊逻辑，代码意图更清晰。

• 框架风格一致性：Spring框架内部在处理Class对象的映射缓存时，很多类似场景都用了IdentityHashMap。保持统一的实现风格，能让维护团队更熟悉代码模式，也避免了随意切换Map类型可能带来的潜在风险。

内容的提问来源于stack exchange，提问作者Stuart