Todos conocemos la diferencia entre usar == y anular el método de iguales al juzgar si los objetos son iguales. De forma predeterminada, equals también se implementa mediante == comparar direcciones, por lo que cuando queremos comparar en función del contenido específico del objeto (como juzgar si dos estudiantes son la misma persona, podemos determinar comparando la identificación del estudiante: studentA .getId () == studentB.getId ()), anularemos el método equals:
//比如在Student类里
public boolean equals(Object obj) {
Student t=(Student)obj;
return (this.id == obj.id);
}
Generalmente, el método equals se sobrescribe aquí, entonces, ¿por qué se recomienda sobrescribir el método hashCode () juntos? Sabemos que, por defecto, el método hashCode () es un método nativo, que compara la dirección del objeto, si la dirección del objeto es diferente, el hashCode devuelto también es diferente.
Cuando colocamos un objeto en una colección, como un Conjunto, primero confirmamos la posición de ubicación a través del valor del código hash del objeto y luego juzgamos si hay datos duplicados en la posición actual. Si no se sobrescribe, los códigos hash de studentA y studentB deben ser diferentes y se colocarán en posiciones diferentes, por lo que la función de deduplicación de conjuntos no será válida.
En resumen, cuando Jdk recomienda anular los iguales, el método hashCode también debe anularse. Es posible que no se use actualmente, pero cuando se usa más adelante, puede causar problemas, como cuando se trata de colecciones.