Take the 2-minute tour ×

What value is hashCode() method is returning in java?

I read that it is an memory reference of an object... When I print hash value for new Integer(1) it is 1; for String("a") is 97.

I am confused: is it ASCII or what type of value is?

share|improve this question

6 Answers 6

up vote 29 down vote accepted

A hashcode is an integer value that represents the state of the object upon which it was called. That is why an Integer that is set to 1 will return a hashcode of "1" because an Integer's hashcode and its value are the same thing. A character's hashcode is equal to it's ASCII character code. If you write a custom type you are responsible for creating a good hashCode implementation that will best represent the state of the current instance.

share|improve this answer

The value returned by hashCode() is by no means guaranteed to be the memory address of the object. I'm not sure of the implementation in the Object class, but keep in mind most classes will override hashCode() such that two instances that are semantically equivalent (but are not the same instance) will hash to the same value. This is especially important if the classes may be used within another data structure, such as Set, that relies on hashCode being consistent with equals.

If you want a hashCode() that uniquely identifies an instance no matter what, use System.identityHashCode() - this will delegate to the default hashCode method regardless of whether it has been overridden.

share|improve this answer
Any particular reason this was modded down? If something here is incorrect I would love a correction, but to downvote without explanation adds nothing to the discussion. –  danben Mar 11 '10 at 20:09
A few years ago, Ted Neward explained in blogs.tedneward.com/2008/07/16/… how the OpenJDK implemented Object.hashCode(). The OpenJDK derives the hash code from the object address, but caches this value and returns it to subsequent callers in case the object moves in memory and its address changes. After briefly reviewing the latest code, I found that the implementation seems not to have changed since Neward wrote his article. –  Derek Mahar Apr 27 '10 at 17:35
This would seem to support my answer. –  danben Apr 27 '10 at 20:27
Wouldn't that mean that a moved object hashcode could hit another new object's hashcode? –  devoured elysium Mar 8 '12 at 20:26
Yes: it could "hit" another new object's hashcode. Hashcodes are not to be considered unique. The "hashcode" is designed to "narrow down" uniqueness (for Hashtables), but you must always follow it with "equals". –  ChrisCantrell Nov 12 '12 at 0:09

If you want to know how they are implmented, I suggest you read the source. If you are using an IDE you can just + on a method you are interested in and see how a method is implemented. If you cannot do that, you can google for the source.

For example, Integer.hashCode() is implemented as

   public int hashCode() {
       return value;

and String.hashCode()

   public int hashCode() {
       int h = hash;
       if (h == 0) {
           int off = offset;
           char val[] = value;
           int len = count;

           hash = h;
       return h;
share|improve this answer
I've planned to answer precisely the same way; +1 –  incarnate Mar 13 '10 at 7:05
@Peter Lawrey and how can I see the Object hashCode implementation –  Java Geek Oct 7 '13 at 9:43
@naroji Its in the OpenJDK. Unfortunately there are multiple strategies and its not clear which one is used. –  Peter Lawrey Oct 7 '13 at 13:39
I went to OpenJDK Object class, but there also it is defined as native.. hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/classes/… –  Java Geek Oct 8 '13 at 4:10

Object.hashCode() used to return a memory address about 14 years ago. Not since.

share|improve this answer
This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. –  chsdk May 24 at 13:59

The hashCode() method is often used for identifying an object. I think the Object implementation returns the pointer (not a real pointer but a unique id or something like that) of the object. But most classes override the method. Like the String class. Two String objects have not the same pointer but they are equal:

new String("a").hashCode() == new String("a").hashCode()

I think the most common use for hashCode() is in Hashtable, HashSet, etc..

Java API Object hashCode()

Edit: (due to a recent downvote and based on an article I read about JVM parameters)

With the JVM parameter -XX:hashCode you can change the way how the hashCode is calculated (see the Issue 222 of the Java Specialists' Newsletter).

HashCode==0: Simply returns random numbers with no relation to where in memory the object is found. As far as I can make out, the global read-write of the seed is not optimal for systems with lots of processors.

HashCode==1: Counts up the hash code values, not sure at what value they start, but it seems quite high.

HashCode==2: Always returns the exact same identity hash code of 1. This can be used to test code that relies on object identity. The reason why JavaChampionTest returned Kirk's URL in the example above is that all objects were returning the same hash code.

HashCode==3: Counts up the hash code values, starting from zero. It does not look to be thread safe, so multiple threads could generate objects with the same hash code.

HashCode==4: This seems to have some relation to the memory location at which the object was created.

HashCode>=5: This is the default algorithm for Java 8 and has a per-thread seed. It uses Marsaglia's xor-shift scheme to produce pseudo-random numbers.

share|improve this answer

Object.hashCode(), if memory serves correctly (check the JavaDoc for java.lang.Object), is implementation-dependent, and will change depending on the object (the Sun JVM derives the value from the value of the reference to the object).

Note that if you are implementing any nontrivial object, and want to correctly store them in a HashMap or HashSet, you MUST override hashCode() and equals(). hashCode() can do whatever you like (it's entirely legal, but suboptimal to have it return 1.), but it's vital that if your equals() method returns true, then the value returned by hashCode() for both objects are equal.

Confusion and lack of understanding of hashCode() and equals() is a big source of bugs. Make sure that you thoroughly familiarize yourself with the JavaDocs for Object.hashCode() and Object.equals(), and I guarantee that the time spent will pay for itself.

share|improve this answer

Your Answer


