0

I got the issue that two integer resolved to the same hashcode in the testcase as below:

public class Test {

private final static Logger log = LoggerFactory.getLogger(Test.class);

private final static LinkedHashMap<Integer,Integer> map = new LinkedHashMap<Integer,Integer>();
/**
 * @param args
 */
public static void main(String[] args) {
    int j=0;
    for(int i=0;i<10000;i++){
        ++j;
        int hash = System.identityHashCode(i);
        if(map.containsKey(hash)){
            log.info("hashcode of key "+i+" was conflict with "+map.get(hash)+" hashcode was:"+hash);
        }else{
            map.put(hash, i);
        }
    }
    log.info("length of map:"+map.size()+" expected:"+j);
}
}

The output is as below:

2014-02-08 12:10:59,723 [main] INFO: hashcode of key 1947 was conflict with 422 hashcode was:9578500  <reactive.lib.Test>
2014-02-08 12:10:59,725 [main] INFO: hashcode of key 2246 was conflict with 1966 hashcode was:14850080  <reactive.lib.Test>
2014-02-08 12:10:59,736 [main] INFO: length of map:9998 expected:10000  <reactive.lib.Test>

I expected that all Integer has a unique hashcode - can anyone explain? If it helps, this test was under JDK1.6 on Windows.

Krease
  • 15,805
  • 8
  • 54
  • 86
Gazit
  • 13
  • 2
  • 2
    That's fine. How many values in `Long` are their? How many values in `int` are there? Clearly not all hash values can be unique - see [the Pigeonhole principle](http://en.wikipedia.org/wiki/Pigeonhole_principle). (This is why HashMap uses the hash to find the bucket, but uses equals for the final check.) – user2864740 Feb 08 '14 at 04:23
  • This is what a hash value is. – Hot Licks Feb 08 '14 at 04:54

1 Answers1

2

You're using System.identityHashCode:

Returns the same hash code for the given object as would be returned by the default method hashCode(), whether or not the given object's class overrides hashCode().

For Integer, it overrides hashCode() so that each value's hashcode is equal to its int value. By using this function instead of hashCode(), you're likely to get a lot more collisions.

In general, hash codes are allowed to be non-unique - it's possible that hashCode() returns 1 for all objects and it would still be valid. It is only required to return the same number for objects that are equal, and is recommended they be as non-unique as possible to make using hashtables more efficient.

From the javadoc:

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.

If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hash tables.

Krease
  • 15,805
  • 8
  • 54
  • 86
  • Is that Java specific? – Mike Cheel Feb 08 '14 at 04:23
  • that would be possible when you write your own hashcode, but i was using default hashcode of Integer. the underlying hashcode of Integer was original value: – Gazit Feb 08 '14 at 04:24
  • The question was tagged with jdk, so I answered java specific. I would expect a similar contract to hold true for other languages. – Krease Feb 08 '14 at 04:26
  • You're not using the integer hashCode method; you're using identityHashCode which effectively computes a code based on the address of the object. Note that this method doesn't even fulfill the contract for hashCode(), in that two integer objects with the same value can have unequal identity hash codes! – Ernest Friedman-Hill Feb 08 '14 at 04:31
  • updated answer now that I noticed @Gazit is using `System.identityHashCode` and not `hashCode` – Krease Feb 08 '14 at 04:34
  • I have tested the code in linux, but did not see any Integer hashcode collision caused by identityHashCode, it's werid. Anyway i think you have answered my question. – Gazit Feb 09 '14 at 06:51