为什么 super.hashCode 对来自同一个 Class 的对象给出不同的结果？

Question

I have a class DebugTo where if I have two equal instances el1 , el2 a HashSet of el1 will not regard el2 as contained.

import java.util.Objects;

public class DebugTo {

  public String foo;

  public DebugTo(String foo) {
    this.foo = foo;
  }

  @Override
  public int hashCode() {
    System.out.println(super.hashCode());
    return Objects.hash(super.hashCode(), foo);
  }

  @Override
  public boolean equals(Object o) {

    if (this == o) {
      return true;
    }
    if (o == null || getClass() != o.getClass()) {
      return false;
    }
    DebugTo that = (DebugTo) o;
    return Objects.equals(foo, that.foo);
  }

}

var el1 = new DebugTo("a");
var el2 = new DebugTo("a");
System.out.println("Objects.equals(el1, el2): " + Objects.equals(el1, el2));
System.out.println("Objects.equals(el2, el1): " + Objects.equals(el2, el1));
System.out.println("el1.hashCode(): " + el1.hashCode());
System.out.println("el2.hashCode(): " + el2.hashCode());

Objects.equals(el1, el2): true
Objects.equals(el2, el1): true
1205483858
el1.hashCode(): -1284705008
1373949107
el2.hashCode(): -357249585

From my analysis I have gathered that:

• HashSet::contains calls hashCode not equals (relying on the Objects.equals(a, b) => a.hashSet() == b.hashSet() )
• super.hashCode() gives a different value both times.

Why does super.hashCode() give different results for el1 and el2 ? since they are of the same class, they have the same super class and so I expect super.hashCode() to give the same result for both.

The hashCode method was probably autogenerated by eclipse. If not answered above, why is super.hashCode used wrong here?

Answer 1

1. Because the default implementations of the equals and hashCode methods (which go hand in hand - you always override both or neither) treat any 2 different instances as not equal to each other. If you want different behaviour, you override equals and hashCode, and do not invoke super.equals / super.hashCode , or there'd be no point.

2. HashSets work as follows: They use .hashCode() to know which 'bucket' to put the object into, and if 2 objects end up in the same bucket, equals is used only on those very few objects to double check.

In other words, these are the rules:

1. If a.equals(b) , then b.equals(a) must be true.
2. a.equals(a) must always be true.
3. If a.equals(b) and b.equals(c) , a.equals(c) must be true.
4. If a.equals(b) , a.hashCode() == b.hashCode() must be true.
5. The reverse of 4 does not hold: If a.hashCode() == b.hashCode() , that doesn't mean a.equals(b) , and hashset does not require it.
6. Therefore, return 1; is a legal implementation of hashCode.
7. If a class has really bad hashcode spread (such as the idiotic but legal option listed in bullet 6), then the performance of hashset will be very bad. eg set.containsKey(k) which ordinarily takes constant time, will take linear time instead if your objects are all not-equal but have the same hashCode. Hence, do try to ensure hashcodes are as different as they can be.
8. HashSet and HashMap require stable objects, meaning, their behaviour when calling hashCode and equals cannot change over time.
9. From the above it naturally follows that overriding equals and not hashCode or vice versa is necessarily broken.

Breaking any of the above rules does not, generally, result in a compiler error. It often doesn't even result in an exception. But instead it results in bizarre behaviour with hashsets and hashmaps: You put an k/v pair in the map, and then immediately ask for the value back and you get null back instead of what you put in, or something completely different. Just an example.

---

NB: One weird effect of all this is that you cannot add equality-affecting state to subclasses , unless you apply a caveat that most classes including all classes in the core libraries don't apply.

Imagine as an example that we invent the notion of a 'coloured' arraylist. You could have a red '["Hello", "World"]' list, and a blue one:

class ColoredArrayList extends ArrayList {
  Color color;

  public ColoredArrayList(Color c) {
    this.color = color;
  }
}

You'd probably want an empty red list to not equal an empty blue one. However, that is impossible if you intend to follow the rules. That's because the equals/hashCode impl of ArrayList itself considers any other list equal to itself if it has the same items in the same order. Therefore:

List<String> a = new ArrayList<String>();
ColoredList<String> b = new ColoredList<String>(Color.RED);

a.equals(b); // this is true, and you can't change that!

Therefore, b.equals(a) must also be true (your impl of equals has to say that an empty red list is equal to an empty plain arraylist), and given that an empty arraylist is also equal to an empty blue one, given that a.equals(b) and b.equals(c) implies that a.equals(c) , a red empty list has to be equal to a blue empty list.

There is an easy solution for this that brings in new problems, and a hard solution that is objectively better.

The easy solution is to define that you can't be equal to anything except exact instances of yourself, as in, any subclass is insta-disqualified. Imagine ArrayList 's equals method returns false if you call it with an instance of a subclass of ArrayList. Then you could make your colored list just fine. But, this isn't necessarily great, for example, you probably want an empty LinkedList and an empty ArrayList to be equal.

The harder solution is to introduce a second method, canEqual , and call it. You override canEqual to return 'if other is instanceof the nearest class in my hierarchy that introduces equality-relevant state'. Thus, your ColoredList should have @Override public boolean canEqual(Object other) { return other instanceof ColoredList; } @Override public boolean canEqual(Object other) { return other instanceof ColoredList; } .

The problem is, all classes need to have that and use it, or it's not going to work, and ArrayList does not have it. And you can't change that.

Project Lombok can generate this for you if you prefer. It's not particularly common; I'd only use it if you really know you need it.