Does hashcode number represent the memory address?

Question

I have learned that hashcode is a Unique Identification reference number, which is a hexadecimal number.
My doubt is, does the reference number represents the memory address of the object?

For example:

Employeee e1=new Employee();
System.out.println(e1.hashcode());

Will this code return me the memory address of my object?

It's a unique value for that object; it need not represent the memory address. Even if it did, what would it mean to you? What would you do with that knowledge? — duffymo, May 07 '13 at 12:12
It is **not** a unique value for that object. It is just a value that is hopefully as unique as it gets (if implemented right). `Object#hashCode` is only unique if pointers are 32-bit. — Marko Topolnik, May 07 '13 at 12:14
@duffymo There are lot of operations that u can do knowing the hashcode buddy.I think u r unaware of that — user2301829, May 07 '13 at 12:22
I'm not your buddy. Please enlighten me as to what those operations might be. — duffymo, May 07 '13 at 12:43
I believe duffymo ment what would you do with the memory address, not what would you do with a hashcode — Scott Chamberlain, May 07 '13 at 12:48
http://stackoverflow.com/questions/16105420/java-object-hashcode-address-or-random — Mikhail, May 08 '13 at 08:07

Michal Borek · Accepted Answer · 2013-05-07T13:04:53.463

13

Hashcode is not a unique identification. It's just a number that helps you distinguish objects. Two different objects may have the same hash code and it is fine.

HashCode characteristics:

If obj1 and obj2 are equal, they must have the same hash code.
If obj1 and obj2 have the same hash code, they do not have to be equal.

edited May 07 '13 at 13:04

answered May 07 '13 at 12:11

Michal Borek

4,584
2
30
40

2

2. is not exactly a rule :) – Marko Topolnik May 07 '13 at 12:22
@Michal Borek I have read that only string objects can have same hashcode coz they may get stored in string constant pool, the rest of the objects always have a different hashcode? what do u think of it – user2301829 May 07 '13 at 12:25
Thanx for ur comments guys,I think I need to do a lot more research nw!! – user2301829 May 07 '13 at 12:31
1

@MarkoTopolink it is a rule due to the [pidigionhole principle](http://en.m.wikipedia.org/wiki/Pigeonhole_principle). You could create more objects than possible values, when that happens two objects that are not equal must have the same hash code. – Scott Chamberlain May 07 '13 at 12:54
The 2. is correct!. "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." Please Check: https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode() – karlihnos May 31 '17 at 14:12

Stefano Sanfilippo · Answer 2 · 2013-05-07T12:32:13.507

3

Not necessarily the memory address. It should be kept different for different objects. But it might be anything. You can also override default hashCode definition with your own.

edited May 07 '13 at 12:32

answered May 07 '13 at 12:12

Stefano Sanfilippo

32,265
7
79
80

In fact, for recent JVMs the default behavior is that the identity hashcode is not even related to a memory address. – Stephen C Aug 11 '19 at 06:19

score 3 · Answer 3 · answered May 07 '13 at 12:13

If Employee class hasn't overridden the hashCode() method , then it will use the one defined in its super class, probably Object class . hashCode() in Object class says ,

As much as is reasonably practical, the hashCode method defined by class Object
does return distinct integers for distinct objects. (This is typically 
implemented by converting the internal address of the object into an integer, 
but this implementation technique is not required by the JavaTM 
programming language.)

So, in short it may or may not depending upon the implementation.Suppose, if Employee class has overridden the hashCode() as(though bad practice and useless) :

public int hashCode() {
   return 10;
}

Then, you can see that it doesn't return a memory address here.

Juned Ahsan · Answer 4 · 2013-05-13T11:30:16.213

Hashcode is a number used by JVM for hashing in order to store and retrieve the objects. For example, when we add an object in hashmap, JVM looks for the hashcode implentation to decide where to put the object in memory. When we retrieve an object again hashcode is used to get the location of the object. Note that hashcode is not the actual memory address but its a link for JVM to fetch the object from a specified location with a complexity of O(1).

Suresh Atta · Answer 5 · 2013-05-07T12:23:26.783

hashCode is the native implementation which provides the memory address to a certain extent.

Any ways you can ovveride it.

If you look close at API

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.

I do not know how much you understand from others answers but my doubts were clear after I read

The 3 things you should know about hashCode() by @Ralf Sternberg

score 2 · Answer 6 · answered May 07 '13 at 12:15

Simple Answer NO

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.

So for your class you can implement the hashcode Method and return whatever you want.

score 1 · Answer 7 · answered May 07 '13 at 12:13

According to Java documentation:

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the Java programming language.)

score 1 · Answer 8 · answered May 07 '13 at 12:15

1

The hashcode for objects is implementation-specific, but I would highly doubt any JVM implementation would use the memory address. Since garbage collection is a central feature of Java, that means the object could be moved and thereby have different memory addresses during its lifetime, even if its contents remain unchanged (and this would violate the hashcode spec).

answered May 07 '13 at 12:15

Tony the Pony

40,327
71
187
281

It could be the int value of the initially valid pointer, though. – Marko Topolnik May 07 '13 at 12:18
1

Yes, that's true -- but you could never safely assume `hashcode == memory address` – Tony the Pony May 07 '13 at 12:19
Of course, especially since pointers can be more than 32-bit, so that would preclude even the theoretical chance. – Marko Topolnik May 07 '13 at 12:21
@TonythePony does that mean this is total BS (where they say it IS the memory address) https://dzone.com/articles/working-with-hashcode-and-equals-in-java – killjoy Nov 16 '18 at 21:42

score 0 · Answer 9 · answered May 07 '13 at 12:13

0

Hashcode is the 32 bit signed integer that is uniquely assigned to that object. It is the result of the hash function when inserting into the hashmap

answered May 07 '13 at 12:13

William Falcon

9,813
14
67
110

Does hashcode number represent the memory address?

9 Answers9

Linked

Related