The default implementation in the Object class is : return this == obj . That is to say, it will only return true if this and obj refer to the same object.
And we often need to use equals to judge whether two objects are equivalent, rather than verifying their uniqueness. In this way, when we implement our own class, we must override equals.
By convention, equals must satisfy the following rules.
Reflexivity: x.equals(x) must be true
For null : x.equals(null) must be false
Symmetry: x.equals(y) and y.equals(x) have the same result
Transitivity : a and b equals, b and c equals, then a and c must also be equals.
Consistency : During a runtime, changes in the state of the two objects will not affect the decision result of equals, then, during this runtime, no matter how many times equals is called, the same result is returned.
hashCode()
This method returns the hash code of the object, the return value is the hash code of type int.
The hash code of the object is to better support the Java collection classes based on the hash mechanism, such as Hashtable, HashMap, HashSet, etc.
Regarding the hashCode method, the consistent convention is that objects that override the euqls method must also override the hashCode() method.
If two objects return true after being called by equals, then the hashCode method of the two objects must also return the same int hash code
If 2 objects return false via equals, their hashCode returns are allowed to be the same.
Two obj, if equals() are equal, hashCode() must be equal.
Two obj, if hashCode() is equal, equals() is not necessarily equal (Hash hash values collide, although the probability is very low).
So: it can be considered that in a set, the rules for judging whether two objects are equal are:
The first step, if the hashCode() is equal, then check the second step, otherwise it is not equal;
The second step is to check whether equals() is equal. If they are equal, the two objs are equal, otherwise they are not equal.
Why always override hashCode when overriding equals
A very common source of errors is not overriding the hashCode method. In every class that overrides the equals method, the hashCode method must also be overridden. Failure to do so would violate the general contract of Object.hashCode and prevent the class from functioning properly with all hash-based collections, such as HashMap, HashSet, and Hashtable.
1. During the execution of the application, as long as the information used in the comparison operation of the equals method of the object is not modified, the hashCode method must consistently return the same integer when the same object is called multiple times. During multiple executions of the same application, the integers returned by each execution may be inconsistent.
2. If two objects compare equal according to the equals() method, then calling the hashCode method of either object must produce the same integer result.
3. If the two objects are not equal according to the equals() method, then calling the hashCode method of any of the two objects does not necessarily produce the same integer result. But programmers should be aware that it is possible to improve hash table performance by producing distinct integer results for unequal objects.
Specification 1: If you rewrite the equals(Object obj) method, it is necessary to rewrite the hashcode() method to ensure that the two objects whose result is true through the equals(Object obj) method have equal hashcode() return values. To put it simply: "If two objects are the same, then their hashcodes should be equal". But please note: this is just a specification, if you have to write a class that equals(Object obj) returns true and hashcode() returns two unequal values, it will compile and run without error. However, this violates the Java specification, and the program also buried a BUG.
Specification 2: If equals(Object obj) returns false, that is, the two objects are "not the same", it is not required to call the hashcode() method on these two objects to obtain two different numbers. The simple point is: "If two objects are not the same, their hashcodes may be the same".
From these two specifications, the following inferences can be drawn:
1. If two objects are equals, the Java runtime environment will think that their hashcodes must be equal.
2. If two objects are not equals, their hashcodes may be equal.
3. If two objects have equal hashcodes, they are not necessarily equals.
4. If the hashcodes of two objects are not equal, they must not be equals.
The default implementation of equals() in Object is to compare whether two objects are ==, that is, the effect of equals and == is the same.
First: During a runtime period, as long as the object's (field) changes do not affect the decision result of the equals method, then, during this period, no matter how many times hashCode is called, the same hash code must be returned.
Second: The hashCode of the 2 objects that return true through the equals call must be the same.
Third: The hash codes of the two objects that return false through equalsl do not need to be different, that is, the return value of their hashCode method allows the same situation.
To sum up in one sentence: equivalent (calling equals returns true) objects must produce the same hash code. Non-equivalent objects do not require the generated hash codes to be different.