Skip to content

Commit f9db913

Browse files
committed
add Article 9 for effective java
1 parent aaca861 commit f9db913

File tree

1 file changed

+14
-1
lines changed

1 file changed

+14
-1
lines changed

docs/effective-java.md

Lines changed: 14 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -887,4 +887,17 @@ public boolean equals(Object o) {
887887

888888
- **覆盖 equals 时总是要覆盖 hashCode(见第 9 条)**
889889
- **不要企图让 equals 方法过于智能**
890-
- **不要将 equals 声明中的 Object 对象替换为其他的类型**
890+
- **不要将 equals 声明中的 Object 对象替换为其他的类型**
891+
892+
### 第 9 条:覆盖 equals 总要覆盖 hashCode
893+
一个很常见的错误根源在于没有覆盖 hashCode 方法。在每个覆盖 equals 方法的类中,也必须覆盖 hashCode 方法。如果不这样做的话,就会违反 Object.hashCode 的通用约定,从而导致该类无法结合所有基于散列的集合一起正常运作,这样的集合类包括 HashMap、HashSet 和 HashTable。
894+
895+
下面是约定的内容,摘自 Object 规范[JavaSE6]
896+
897+
- 在应用程序执行期间,只要对象的 equals 方法的比较操作所用到的信息没有被修改,那么对这同一个对象调用多次,hashCode 方法都必须始终如意的返回同一个整数。在同一个应用程序的多次执行过程中,每次执行所返回的整数可以不一致。
898+
899+
- 如果两个对象根据 equals(Object) 方法比较是相等的,那么调用两个对象中任意一个对象的 hashCode 方法都必须产生同样的整数结果。
900+
901+
- 如果两个对象根据 equals(Object) 方法比较是不相等的,那么调用两个对象中任意一个对象的 hashCode 方法,则不一定要产生不同的整数结果。但是作为程序员应该知道,给不相等的对象产生截然不同的整数结果,有可能提高散列表(hashTable)的性能。
902+
903+
**因没有覆盖 hashCode 而违反的关键约定是第二条:相等的对象必须具有相等的散列码(hash code)**。根据类的 equals 方法,两个截然不同的实例在逻辑上是有可能相等的,但是,根据 Object 类的 hashCode 方法,它们仅仅是两个没有共同之处的对象。因此,对象的 hashCode 方法返回两个看起来是随机的整数,而不是根据第二个约定所要求的那样,返回两个相等的整数。

0 commit comments

Comments
 (0)