The way to properly rewrite equals() and hashCode() in Java is the key to ensuring that objects work properly in collection classes. If you only rewrite equals() and not hashCode(), objects with the same content will be mistaken for different keys, because the hash set depends on hashCode() to determine the storage location. 1. When rewriting equals(), you should first check whether it is the same object, whether it is null or type mismatch, and then compare fields one by one; 2. Rewriting hashCode() must be consistent with equals(), and commonly used Objects.hash() to generate comprehensive hash values; 3. Use the IDE automatic generation method to avoid errors and improve readability; 4. Pay attention to its default behavior when using Lombok, and do not let hashCode() return constants; 5. Be especially careful when modifying fields of mutable objects that may cause search failures.

Correctly rewriting equals() and hashCode() methods in Java is the key to ensuring that objects work normally in collection classes (such as HashMap, HashSet). If these two methods are not used in conjunction or are improperly implemented, it may lead to unexpected errors, such as the same object cannot be recognized as "equal", or it cannot be found after being placed in a HashSet.

Let’s talk about how to do this correctly from the perspective of actual development.

Why must equals() and hashCode() be rewrite together

Java's Object class has implemented these two methods by default, but they are based on the memory address of the object. When you customize classes and want to determine whether they are equal based on the content, you have to rewrite them.

If you only rewrite equals() and not hashCode() , then even if the contents of the two objects are the same, they may still be treated as different keys in HashSet or HashMap. Because hash collections rely on hashCode() to decide which bucket to store the object.

Simply put:

• equals() determines whether two objects are "logically the same"
• hashCode() determines where this object should be placed in the hash structure

If the two are inconsistent, there will be problems.

How to correctly rewrite equals()

When rewriting equals() , there are several basic rules that need to be followed:

1. Check whether it is the same object : if (this == obj) return true;
2. Check whether it is null or type mismatch : if (obj == null || getClass() != obj.getClass()) return false;
3. Compare fields one by one after cast : Objects.equals() is usually used to safely compare reference type fields

For example, a simple User class:

 @Override
public boolean equals(Object obj) {
    if (this == obj) return true;
    if (!(obj instanceof User)) return false;
    User other = (User) obj;
    return Objects.equals(name, other.name) &&
           age == other.age;
}

Note that instanceof is used here to determine the type, rather than directly comparing getClass() . Both methods are OK, but the behavior is different in inheritance scenarios. It is generally recommended to use getClass() to ensure that both sides are exactly the same class.

How to correctly rewrite hashCode()

hashCode() must be consistent with equals() : if two objects are considered equal through equals() , their hashCode() must return the same value.

A common practice is to use Objects.hash() method to generate a hash value that combines multiple fields:

 @Override
public int hashCode() {
    return Objects.hash(name, age);
}

Although simple, pay attention to performance and distribution uniformity. If there are many fields or performance requirements, you can consider manually combining hash values, such as using prime multiplication and other methods to optimize.

Use the IDE to automatically generate more troublesome

Modern IDEs such as IntelliJ IDEA or Eclipse support automatic generation of equals() and hashCode() methods. You can choose the fields to participate in the comparison, and the IDE will help you generate code that complies with the specification.

The benefits of doing this are:

• Avoid mistakes that are easy to make when writing
• Strong readability and clear structure
• Easier to maintain

However, you still need to understand the principle behind it, otherwise you won’t know what’s wrong with the field if you correct it.

Small details reminder

• If you use Lombok, you can use the @EqualsAndHashCode annotation to generate automatically, but be careful that it will not process the parent class field by default (unless callSuper = true )
• Don't let hashCode() return a constant. Although this can pass the test, it will cause all objects to fall into the same hash bucket, which seriously affects performance.
• For mutable objects, if the fields are modified after being placed in the collection, it may cause the subsequent search. Be especially careful in this situation.

Basically that's it.

The above is the detailed content of Correctly Overriding equals() and hashCode() in Java. For more information, please follow other related articles on the PHP Chinese website!