奇怪的Java Hashcode（带有Lombok）不确定性行为

Question

I'm getting some behavior that I don't understand with Java Hashcode (using Lombok). I've got an abstract object Storable for things that I'm storing in various DataStores.

public abstract class Storable implements Serializable {
  ...
}

@Data
@EqualsAndHashCode(of="url", callSuper=false)
@Slf4j
@ToString(of="url")
public final class Foo extends Storable {

  private URL url;

  public Foo(@NonNull URL url, ...) {

    super();
    this.url = url;
    ...
  }

  ...
}

When I new up multiple Foos with new Foo(new URL(" http:///www.foo.com ")) and I iterate over them and check each foo.hashCode() I get the same value. But if I terminate the program and then start another run, the foos in the new run have a different hashCode value even though they look identical from a data standpoint. The discrepancy is causing me grief because I'm trying to use hashCode to identify unique objects from run to run. Perhaps even more oddly, for a given URL that I'm using for testing I'm seeing 1 of the same 4 integers every time.

Am I missing something about either Java's default getHashcode() implementation or Lombok's @EqualsAndHashCode implementation? Or is there something about URL that would cause it to have a different hashCode value? Thanks in advance for the help!

Answer 1

If you are using Java 7 this is probably using the alternate murmur hashcode implementation which is not guaranteed to produce the same hashcode across JVM instances (or the same JVM run multiple times)

Article that discusses the change to hashcode in Java 7

Relevant section:

A couple more words about the alternative hash code:

• it isn't exposed publicly through the String class. You can access it using the (unofficial) sun.misc.Hashing.stringHash32 method

• unlike the original hash code, hash32 for two strings containing the same characters but running in different JVMs (on the same machine or on different machines) isn't guaranteed to be the same (in fact most likely it won't be, since a “HASHING_SEED” value is included in the calculation which is initialized on JVM startup using the current time)

• the purpose of alternative hash code is to give better performance for HashMap and related classes with String keys and to thwart hash-collision denial of service attacks

• Its usage isn't enabled by default. You need to set the “jdk.map.althashing.threshold” property to enable it. If you set this to a value X, then HashMap and related classes with a capacity at least X will use the alternative hashing algorithm.

A word of caution if you want to enable alternative hashing: prior to Java 7u40 (ie. all versions between Java 7u6 and Java 7u39) had a performance issue which meant that HashMap creation while alternative hashing was enabled was slower than needed to be. Thus if you want to enable alternative hashing, ensure that you have the latest Java 7 runtime.

This was added in Java 7u6 but has been removed in Java 8.

Here's the internal implementation of Java 7's murmur hash function on grep code .

Here's the link to Java 7's HashMap implementation that uses the new hash code calculation if the key in the map is a String http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/java/util/HashMap.java#HashMap.hash%28java.lang.Object%29

Answer 2

The hash code of an object is not in general required to be deterministic. Only if the documentation of a class explicitly says the hash code is deterministic may you assume it is deterministic.