Get unique identifier of a Thread in Java 1.4

Question

In Java 1.4, is there any better way of getting a Thread's ID than using Thread.getName()?

I mean, getName() in unit tests returns something like "Thread-1", but in WebLogic 10 I get "[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'.xml".

Ok we need some more info here. Are you interested in all threads or just the ones that you create (sounds like all)? Do you need the same value to be returned with each run of the unit tests or can the returned value be different each time the unit tests are run? — TofuBeer, Mar 31 '09 at 15:51

score 8 · Accepted Answer · edited May 23 '17 at 12:34

8

Thread.getId (it can theoretically overflow, but it is defined not to and in practice will not).

1.5 is going through its End of Service Life period now, but if you are using old dusty-decks 1.4, then you can implement your own with ThreadLocal. (Note, don't follow the Java SE 6 API docs too closely!)

edited May 23 '17 at 12:34

Community

1
1

answered Mar 31 '09 at 14:43

Tom Hawtin - tackline

145,806
30
211
305

That is just the implementation by Sun though, it could be changed to not simply to ++ and actually be aggressive at reuse. Odds of that happening are likely low, and odds of a different implementation, say the Classpath project, using a different method is slim. – TofuBeer Mar 31 '09 at 14:55
Classpath (isn't it dead yet) and Harmony could use a different, egregiously non-compliant implementations, but in practice that is only a theoretical possibility. – Tom Hawtin - tackline Mar 31 '09 at 15:06
@Tom Hawtin: But the API docs specifically state, "When a thread is terminated, this thread ID may be reused." – Michael Myers Mar 31 '09 at 15:09
Ha, yeah, I got caught up in looking at the wrong problem. Never mind. – Michael Myers Mar 31 '09 at 15:16
@Tom, that is what I am saying, there is Classpath and other implementations that may not mimic the behaviour of reuse that the Sun implementation does. How can you have "egregiously non-compliant implementations" if the behaviour isn't specified? – TofuBeer Mar 31 '09 at 15:43

score 3 · Answer 2 · answered Mar 31 '09 at 14:43

Why do you need this? Because depending on your answer, there are several approaches.

First, understand that a thread's name is not guaranteed to be unique. Nor is identity hashcode.

If you truly want to associate a unique ID to a thread, you're going to need to do it yourself. Probably using an IdentityHashMap. However, that will introduce a strong reference that you don't want to have hanging around in a production app.

Edit: TofuBeer has solution that's probably better, although the docs note that thread IDs can be reused.

score 3 · Answer 3 · edited May 23 '17 at 10:32

As mentioned in "Thread.getId() global uniqueness question" SO question, and confirmed by the source code of Thread.java:

/* For generating thread ID */
private static long threadSeqNumber;

/* Set thread ID */
tid = nextThreadID();

private static synchronized long nextThreadID() {
    return ++threadSeqNumber;
}

The thread id is very simple to implement yourself if your are still in java1.4.
However this implementation means a given thread will not have the same id when you are running your program several times.
So depending on what you need, you may have to implement a naming policy which is both:

unique for a given runtime session
reused from session to session
still linked to the internal original naming policy managed by the 1.4 JVM ("Thread-1", "Thread-2", ...)

score 2 · Answer 4 · answered Mar 31 '09 at 14:43

2

You can use getID if you are on JDK 1.5 or higher.

Is it the case that you need a consistent value for each time you run the unit tests, or is just a unique value good enough?

answered Mar 31 '09 at 14:43

TofuBeer

60,850
18
118
163

Get unique identifier of a Thread in Java 1.4

4 Answers4