• Post Reply Bookmark Topic Watch Topic
  • New Topic

Hashcode  RSS feed

 
Satyen Singh
Greenhorn
Posts: 21
Java Tomcat Server Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends,

My question is,

can we have 2 objects of same hashcode in java?

if yes, how?

thanks in advance dear friends.
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes.

How? The easiest way is to override hashCode() to return the same value. In fact the following is a perfectly valid (if not very sensible) hashCode() implementation:

Why do you think it would be a problem?
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Satyen Singh wrote:
can we have 2 objects of same hashcode in java?


yes

Satyen Singh wrote:
if yes, how?


The hashCode() method returns the same value for both objects.

Or were you implying something else here?

Henry
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Satyen Singh wrote:Hi Friends,

can we have 2 objects of same hashcode in java?

if yes, how?


How many possible values of hashCode() are there?

How many different values of Long are there?

Now you have your answer.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Satyen Singh wrote:can we have 2 objects of same hashcode in java?

As others have said: yes.

But, as Campbell pointed out in another thread, you have to be very careful what you're asking.
If your question is: can two Objects have the same hashcode - or two objects of any type have the same System.identityHashCode() - the answer is: in a 32-bit JVM, possiby not; in a 64-bit JVM, almost certainly they can.

However, given that the answer is basically 'yes', the idea of a hashcode is that it should, as far as possible, return distinct values for different objects.

Winston
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
If your question is: can two Objects have the same hashcode - or two objects of any type have the same System.identityHashCode() - the answer is: in a 32-bit JVM, possiby not; in a 64-bit JVM, almost certainly they can.


32-bit or 64-bit JVM is irrelevant. hashCode is 32 bits. And, as I pointed out, look at Long.

Oddly enough, I got more collisions on a 32-bit JVM than on a 64-bit.


 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:32-bit or 64-bit JVM is irrelevant. hashCode is 32 bits. And, as I pointed out, look at Long.

Yes, but I've never tried to create more than 4 billion Longs on a 32-bit JVM.

Oddly enough, I got more collisions on a 32-bit JVM than on a 64-bit.

Now that is interesting. Useless, but interesting...Do you watch QI?

Winston
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Jeff Verdegan wrote:32-bit or 64-bit JVM is irrelevant. hashCode is 32 bits. And, as I pointed out, look at Long.

Yes, but I've never tried to create more than 4 billion Longs on a 32-bit JVM.


Why would that matter? The hashCode value doesn't depend on how many you've created so far. 0L and -1L have the same hashCode value, regardless of how many Longs you have or have not created. Same for 1L / -2L, 2L / -3L, and so on.

Oddly enough, I got more collisions on a 32-bit JVM than on a 64-bit.

Now that is interesting. Useless, but interesting...Do you watch QI?


Never heard of it.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:Why would that matter? The hashCode value doesn't depend on how many you've created so far. 0L and -1L have the same hashcode value

I think we're talking at cross-purposes here. I was referring to Object.hashCode() (or System.identityHashCode()), and I would be very surprised if two different Longs had the same identity hash, regardless of value.

Do you watch QI?
Never heard of it.

Great program. Stephen Fry and a bunch of intelligent comedians wittering on about useless trivia. Now in it's (I think) 11th season on the Beeb.

Winston
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Jeff Verdegan wrote:Why would that matter? The hashCode value doesn't depend on how many you've created so far. 0L and -1L have the same hashcode value

I think we're talking at cross-purposes here. I was referring to Object.hashCode() (or System.identityHashCode()), and I would be very surprised if two different Longs had the same identity hash, regardless of value.


I wouldn't. You saw the output of my Object test, right? That's the same as calling identityHashCode() on any object, whether Object, Long, or ThreeToedSloth.

Do you watch QI?
Never heard of it.

Great program. Stephen Fry and a bunch of intelligent comedians wittering on about useless trivia. Now in it's (I think) 11th season on the Beeb.

Winston

Cool. I'll have to check it out.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:
Winston Gutkowski wrote:I would be very surprised if two different Longs had the same identity hash, regardless of value.


I wouldn't. You saw the output of my Object test, right? That's the same as calling identityHashCode() on any object, whether Object, Long, or ThreeToedSloth.


 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:I wouldn't. You saw the output of my Object test, right?

I didn't say it couldn't happen; I just said I'd be surprised if it did - I think even your tests bear that out. It'd also be interesting to know when the first "collision" occurs.

That said, it (the collision rate) is a lot higher than I would have expected.

Winston
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Jeff Verdegan wrote:I wouldn't. You saw the output of my Object test, right?

I didn't say it couldn't happen; I just said I'd be surprised if it did - I think even your tests bear that out.


I wouldn't say 13% bears out "very surprised".

It'd also be interesting to know when the first "collision" occurs.




So after creating less than 2000 objects, I got an identityHashCode collision.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:So after creating less than 2000 objects, I got an identityHashCode collision.

I have to admit I find that very surprising for an address-based hash (which the docs suggest it probably is).

I massaged your test a bit and found that on as little as 3,000,000 objects (couldn't get much past that with my heapspace settings) I was getting chains of 5 duplicates with System.identityHashCode() (none with Long.hashCode()), which suggests to me that an IdentityHashMap may not perform as well as a well-hashed HashMap on large volumes.

All other things being equal - which they aren't, of course.

Winston

[Edit] A little more mucking about and I discovered that the changeover from max. 4 duplicates to max. 5 comes at exactly the same point every time: 1,970,120; and it seems to be directly related (not surprisingly) to the total number of objects created. If I create another object somewhere else in the code, it pushes the number down or up by 1; all of which suggests that it's using some sort of mod of the address rather than the whole thing, which seems a bit hokey to me.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:all of which suggests that it's using some sort of mod of the address rather than the whole thing, which seems a bit hokey to me.


It has to do that. It has to hash the hash to select a bucket. There are 2^32 possible hash values, but our HashMap is not going to have 2^32 buckets.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:It has to do that. It has to hash the hash to select a bucket. There are 2^32 possible hash values, but our HashMap is not going to have 2^32 buckets.

Yes, but that's to do with how HashMap works internally. All I was referring to is the values produced by Long.hashCode() and System.identityHashCode(new Long(value)). 3,000,000 Long objects produced at least one set of 5 duplicate values when using identityHashCode(), whereas hashCode() produced none (admittedly in an artificial situation), which suggests to me that Long's own hash is better than its identity hash, which I find surprising.

That's all, nothing more - it certainly won't stop me using it.

Winston
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Jeff Verdegan wrote:It has to do that. It has to hash the hash to select a bucket. There are 2^32 possible hash values, but our HashMap is not going to have 2^32 buckets.

Yes, but that's to do with how HashMap works internally. All I was referring to is the values produced by Long.hashCode() and System.identityHashCode(new Long(value)).


Ah, I see. My mistake.

3,000,000 Long objects produced at least one set of 5 duplicate values when using identityHashCode(), whereas hashCode() produced none (admittedly in an artificial situation), which suggests to me that Long's own hash is better than its identity hash, which I find surprising.


My guess is that they're equally good for their respective domains. I would imagine that identityHC (Object's HC) probably does some fiddling with the address to produce a good distribution based on how objects are likely to be distributed in physical memory. Printing the hashCodes of 5 consecutively created objects bears this out, in that it shows no immediately recognizable pattern:


For Long, its hashCode() is written to provide reasonable distribution over all long values:

If your artificial situation was 0..2,999,999, then we can see that the hashCodes will simply be those values. So, yes, the artificial situation played right into the hands of no repeats.

For random Longs, I would expect the HC and idHC results to be similar. Here's what I got.



So, I guess my theory needs some refining.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!