In HotSpot, a Java thread may have a couple of different IDs, depending on the context.
Java-level thread ID
This ID could be fetched from java.lang.Thread.getId() or java.lang.management.ThreadMXBean.getAllThreadIds(). It's platform independent.
In Oracle/Sun's JDK implementation, this ID is simply a auto-incrementing long, starting from 1, assigned to each Java-level java.lang.Thread object when they're initialized.
Quote from java.lang.management.ThreadMXBean's JavaDoc:
Thread ID is a positive long value returned by calling the Thread.getId() method for a thread. The thread ID is unique during its lifetime. When a thread is terminated, this thread ID may be reused.
Some methods in this interface take a thread ID or an array of thread IDs as the input parameter and return per-thread information.
Native thread ID
This ID is highly platform dependent. It's the nid in jstack thread dumps.
On Windows, it's simply the OS-level thread ID within a process.
On Linux, it's the pid of the thread (which in turn is a light-weight process).
On Solaris, it's the thread as returned by
On Mac OS X, it is said to be the native pthread_t value.
The Address of a C++-level Thread/JavaThread object
This is also platform dependent. It's the tid in jstack thread dumps.
The valid stack memory region of a JavaThread
// print guess for valid stack memory region (assume 4K pages); helps lock debugging st->print_cr("[" INTPTR_FORMAT "]", (intptr_t)last_Java_sp() & ~right_n_bits(12));
That's the last pair of brackets in a
jstack output for Java threads. If it's showing "0x0000000000000000", then last_Java_sp == NULL, which means there is no last Java frame for this thread.
The correspondence? Serviceability Agent to the rescue
See the Java source files in this gist. To compile them, Project Lombok's lombok.jar and JDK's sa-jdi.jar are required on classpath.