Comments on: Getting A Java Object’s Reference ID

By: Dontell

Dontell — Wed, 07 Jul 2010 07:08:10 +0000

“UPDATE: A number of commenters have pointed out that I’m totally wrong here. Please don’t do this.”

This is so funny, really :-D.

By: infinity0

infinity0 — Tue, 14 Jul 2009 13:13:35 +0000

The blog post is *wrong*. System.identityHashCode() does NOT generate unique IDs for objects. Its only guarantee is that if the codes are different the objects are different, not the other way round. If you rely on this behaviour, your program will see very weird bugs every once in a while.

By: Petr Smid

Petr Smid — Thu, 21 May 2009 15:48:57 +0000

hashCode gives you hash code and NOT any unique ID! Hash code can have colisions. Btw. see API documentation of Object.hashCode().
Whatmore I see no reason to override hashCode() when overriding toString(). ToString method is not ment to return hashCode… just String describing the current instance.

By: Dom Sparks

Dom Sparks — Wed, 06 May 2009 16:35:27 +0000

Agree with the previous comment, and in fact I’m currently looking at some code which is problematic because System.identityHashCode() is returning the same hashcode for two distinct objects. Although I’m sure that previous versions of Sun’s JDK would always produce unique values, it seems that in JDK1.5 (which is what I’m currently using) the value is not necessarily unique. I’m having to change my code so that I generate my own ids for objects as and when they are created, rather than using System.identityHashCode() as an identifier…

By: redmaniac

redmaniac — Sun, 22 Mar 2009 19:22:21 +0000

You should be careful with taking the Object.hashCode for a reference id: According to the Sun Java API the class ‘Object’ implements hashCode in such a way that it really does distinguish any two objects. However, it also states that this behavior is by no means required by the Java Standard, i.e. another java implementation than Sun’s might behave differently in that issue while still being a “correct” java implementation.

By: anonymous

anonymous — Sat, 21 Mar 2009 01:01:28 +0000

I have been looking to get/print such info too. And for a bit, the explanation here seemed convincing. However, when I wrote a small program and when I force the VM to do a “full thread dump” (by hitting Ctrl-Brk on keyboard, or by running jmap and jhat, and look at the output, the instance addresses are totally different. Try it out with this simple program. If you look at the “full thread dump”, look for the main-thread stack and look for what object is in locked state – corresponding to synchronized state here.

Hope somebody has a way of really printing real object references.

public class Foo
{
private String sName;

Foo()
{
;
}

Foo(String s)
{
sName = s;
}

public static void main(String[] args) {
Foo f1 = new Foo(“Hello”);
Foo f2 = new Foo(“Hello”);

Object syncObj = null;
for(int i=0; i < 50000; i++) {
System.out.println(“f1: ” + “0x” + Integer.toHexString(System.identityHashCode(f1)));
System.out.println(“f2: ” + “0x” + Integer.toHexString(System.identityHashCode(f2)));
System.out.println(“Class f1: ” + “0x” + Integer.toHexString(System.identityHashCode(f1.getClass())));

try {
int j = i % 3;
switch (j) {
case 0:
syncObj = f1;
System.out.println(“Synchronizing on f1 obj”);
break;
case 1:
syncObj = f2;
System.out.println(“Synchronizing on f2 obj”);
break;
case 2:
syncObj = f1.getClass();
System.out.println(“Synchronizing on Class obj”);
break;
default:
syncObj = null;
break;
}
synchronized(syncObj) {
Thread.sleep(10000);
}
}
catch (Exception e) { ; }
}

}
}

By: Lorenzo

Lorenzo — Mon, 02 Mar 2009 18:46:41 +0000

This saved my day! Thanks :-)

By: david van brink

david van brink — Fri, 02 Jan 2009 09:17:36 +0000

Thank you!

That clears up a mystery to me. Also solves my problem at hand (where I wanted to print a unique-ish id…)

Going further, in Eclipse, the debugger shows a different object id. Stuff like String[id=73] an other low numbers… any idea where *that* comes from? Guessing it’s unique to its debugger (if it overrides all object-creation) or in the debug API.

ToHexString is AOK. Thanks again.