性能关键在hashCode()和equals()是否合理稳定高效：需分布均匀、不依赖可变字段、与equals逻辑一致；推荐用Objects.hash和IDE生成；优先选String等不可变类作键。
用对象作 HashMap 的键时，性能好坏关键不在对象本身多“重”，而在于 hashCode() 和 equals() 是否合理、稳定、高效。如果这两个方法没写好，轻则哈希冲突激增、查询变慢，重则逻辑出错、数据丢失。
确保 hashCode() 分布均匀且不随状态变化
哈希值分布不均，会导致大量键挤进少数桶里，链表或红黑树变长，O(1)退化为 O(n) 或 O(log n)。尤其要避免：
- 直接返回常量（如
return 42;），所有键都进同一个桶； - 只用对象某个字段（比如 ID）计算哈希，而该字段取值集中（如全是 1~10 的小整数）；
- 在 hashCode() 中依赖可变字段——对象插入 Map 后若字段被修改，再 get 就找不到它（因为哈希值变了，去错了桶）。
推荐做法：对所有参与 equals() 判断的不可变字段组合计算哈希，用 Objects.hash(f1, f2, f3) 简洁又可靠。
重写 equals() 必须与 hashCode() 保持逻辑一致
这是硬性契约。如果两个对象 equals() 返回 true，它们的 hashCode() 必须相等；反之不成立。常见错误：
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
equals()比较了 5 个字段，hashCode()只用了其中 2 个； -
equals()中用了==比较字符串，而没用.equals()； - 子类重写 equals() 但没调用
super.equals()，破坏继承一致性。
IDE（如 IntelliJ）能一键生成符合规范的 equals() 和 hashCode()，优先使用它，别手写。
优先选用不可变对象作键
String、Integer、LocalDate 等 JDK 内置不可变类是理想键类型——它们的哈希值天生稳定，线程安全，无需你操心。自定义键应尽量设计为不可变：
- 所有字段用
final修饰； - 构造器完成全部初始化，不提供 setter；
- 若字段是可变引用类型（如
List），需防御性拷贝或封装为不可变视图。
例如：new Person("Alice", 25) 创建后，名字和年龄就不能再改——这样放进 HashMap 才真正“放心”。
避免在键对象中做耗时操作
每次 put/get 都会调用 hashCode() 和 equals()，如果里面包含文件读取、网络请求、复杂递归计算，性能会断崖式下跌。
- 不要在
hashCode()里调用toString()或拼接长字符串； - 避免遍历集合、格式化日期等操作；
- 若必须缓存计算结果，可用
transient字段 + 懒加载，并注意线程安全（如用AtomicInteger或双重检查锁）。
简单原则：键对象的这两个方法，应该像数学公式一样快而确定。
