简体   繁体   中英

How hashcodes for enums are calculated in Java, and combining enum hashCodes for a HashMap's key

I have a class that contains different enums (different types). This class is used as key for a HashMap . The classes hashCode currently is implemented like this:

  public static class Key implements Comparable<Key> {
    final int a;
    final Enum1 enum1;
    final Enum2 enum2;

    @Override
    public int hashCode() {
      return a ^ enum1.hashCode() ^ enum2.hashCode();
    }

    // ... definition of equals and toString ...
  }

Now if enums hashCode would just return the index of the enum value in the enum's definition, this would not be optimal (too many clashes). The method definition for Enum.hashCode() is this:

/**
 * Returns a hash code for this enum constant.
 *
 * @return a hash code for this enum constant.
 */
public final int hashCode() {
    return super.hashCode();
}

Assuming this delegates to Object.hashCode() , everything should be fine because for every enum constant there only exists one instance, and Object.hashCode() will in theory be something like an integer derived from the internal address of the object. Am I right?

PS: Of course you will have to use something more complex when the same enum is used several times in a key.

Yes, you are right in that the hashcode of an enum element will come from the static instance, bound to memory positions, and be unique.

On the other hand, there are better ways of generating a hashcode with less collision probability. Check out, for example, the defaults that eclipse can autogenerate for you (right click, Source> Generate hashCode and equals)

public int hashCode() {
    final int prime = 31;
    int result = 1;
    result = prime * result + ((enum1 == null) ? 0 : enum1.hashCode());
    result = prime * result + ((enum2 == null) ? 0 : enum2.hashCode());
    return result;
}

By throwing prime numbers into the mix (the precise math escapes me) you are supposed to be a little more resistant.

Note you can also let eclipse generate an equals method for you! (Even a toString). Not saying you must blindly trust them, but they are usually a very good start.

As it is said above,Enum are immutable in the Java, So the hashcode generated for a Enum is a perfect key for a Hash collection,just as the String are perfect keys.

The enum declaration is a special kind of class declaration. An enum type has public, self-typed members for each of the named enum constants. All enum classes have high-quality toString, hashCode, and equals methods. All are Serializable, Comparable and effectively final. None are Cloneable. All of the "Object methods" except toString are final: we take care of comparison and serialization, and ensure t hat it's done right.

In Java 8, you can use Objects.hash() for this purpose.

For example, you can rewrite your hashCode to

//
import static java.util.Objects.hash;

// 
@Override
public int hashCode() {
  return hash(a, enum1, enum2);
}

Just tested this on a Oracle 1.6 JVM. The enum indeed delegates to Object.hashCode(). And it varies between different runs. Keep in mind though that the keys thus aren't stable between different VMs / VM instances. So when you serialize the HashMap and read it back in a different VM, you will not be able to look up values there using keys that have been constructed in that VM.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM