equals 和 hashCode 如何在幕后工作？

Question

I researched this question and the answers I got do not satisfy me as they don't explain these things deeply enough. So, it is known that for HashSet with a parametrized custom class it is necessary to override hashCode and equals in order to forbid duplicates. But in practice when I tried to understand how this really works I didn't quite get it. I have a class:

static class Ball {
    String color;

    public Ball(String color) {
        this.color = color;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Ball ball = (Ball) o;
        return Objects.equals(color, ball.color);
    }

    @Override
    public int hashCode() {
        return Objects.hash(color);
    }
    }

In equals method, it is all clear. If two 'variables' are pointing to the same object in memory, then they are equal; if an o is null or they are not of the same class - they are not equal. The last line of equals is what's concerning me. When I go to the Objects.equals :

public static boolean equals(Object a, Object b) {
    return (a == b) || (a != null && a.equals(b));
}

It says once again if two 'variables' refer the same object, then they are equal or if the first object is not null and it is equal to the second one. This equals is Object.equals which will return true if only these two objects aka 'variables' are pointing to the same object in memory. So, how does this really works? Been looking for a clear answer, but as I said, what I've got so far does not satisfy me at all.

Answer 1

In your class, you explained it very well.

The part that you are missing is that at some point, your code will delegate to the equals and hashCode on the color attribute, which is implemented by the java.lang.String class.

See eg https://github.com/openjdk-mirror/jdk7u-jdk/blob/f4d80957e89a19a29bb9f9807d2a28351ed7f7df/src/share/classes/java/lang/String.java#L1013 and https://github.com/openjdk-mirror/jdk7u-jdk/blob/f4d80957e89a19a29bb9f9807d2a28351ed7f7df/src/share/classes/java/lang/String.java#L1494

Answer 2

tl;dr

return Objects.equals(color, ball.color);

You are passing two String objects here, not Ball objects.

Your override of Object#equals compares Ball objects, while the line above compares the String objects referenced by the color field of Ball .

Details

First, let's clarify the terminology.

This equals is Object.equals which will return true if only these two objects aka 'variables' are pointing to the same object in memory.

In your equals method, both this and Object o are reference variables, not objects. Either variable can hold no reference at all (null) or either variable can hold a reference (pointer) to an object living elsewhere in memory.

Next we can examine your code.

Three Phases of equals

The logic of your equals is three phased:

• Identity check
• Null check
• Content comparison

The first phase performs an identity check . We look to see if both reference variables refer to the same object, the same chunk of memory. If so, there is no need for further consideration: An object is always equal to itself. So return true , job done.

The second phase performs a null check . If either of the two objects being compared is null, we report false , meaning “not equal”. To perform the null check, we skip this . The this reference variable cannot be null by definition. We move on to the Object o . If null, report false , job done.

The third phase compares content . We examine the content of the object referenced by this . And we examine the content of the object referenced by Object o . We know we have two separate objects (two separate chunks of memory) because at this point in the code we got past the identity check.

In your case with the Ball class, you chose to compare the one and only piece of state, the member field color . That member field holds a reference to a String object. So, after casting o to Ball ball , we compare the string from this.color to the string from ball.color .

This seems to be the sticking point in your understanding. 👉 The casting is crucial here. After successfully casting from Object o to Ball ball , the Java Virtual Machine at runtime knows that the object in question is indeed a Ball (or a subclass of Ball ). As a Ball , we have access to its color field.

In the call to Objects.equals(color, ball.color) we are comparing two String objects, not two Ball objects. You may find clarity in expanding that code.

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Ball ball = (Ball) o;
    String thisColor = this.color ; 
    String thatColor = ball.color ; 
    boolean colorsAreTheSame = thisColor.equals( thatColor );
    return colorsAreTheSame ; 
}

You said:

When I go to the Objects.equals :

Your code is passing two String objects to Objects.equal , not two Ball objects.

By the way, do not confuse Objects.equals with Object#equals .

• This first is a static method on the utility class Objects — notice the plural s .
• The second is an instance method defined on the ultimate superclass Object — note the singular, with no s on the end. The second is inherited by Ball , but then overridden by the Ball class' own implementation. So the implementation provided by Object#equals is never used in your scenario.

You said:

This equals is Object.equals which will return true if only these two objects aka 'variables' are pointing to the same object in memory.

You cut it short there. The Object.equals method performs the same three phased logic as your equals method: firstly identity check, secondly null check, and thirdly whatever is implemented in the equals method of the two objects.

And most importantly, you are passing two String objects to Objects.equals , whereas your override of equals compares two Ball objects.

---

By the way, if the purpose of your class is to communicate date transparently and immutably, you can more briefly define the class as a record in Java 16+.

In a record, you merely declare the type and name of each member field. The compiler implicitly creates the constructor, getters, equals & hashCode , and toString .

The default for this methods is to utilize each and every member field. You can override equals & hashCode you want to consider a subset of the member fields.

Here is your entire Ball class when written as a record.

record Ball ( String color ) {}

Usage:

Ball redBall = new Ball( "red" ) ;
Ball blueBall = new Ball( "blue" ) ;
boolean sameBall = redBall.equals( blueBall ) ;  // false