18

Thread.currentThread() is a static method which provides reference to currently executing Thread (basically a reference to 'this' thread).

Accessing non-static members (especially this) inside a static method is not possible in Java, so currentThread() is a native method.

How does currentThread() method work behind the scenes?

Jeffrey Bosboom
  • 13,313
  • 16
  • 79
  • 92
maximus335
  • 674
  • 1
  • 5
  • 19
  • You could look at the OpenJDK code implementing this method. At a guess, I'd say it asks the OS which thread it's on, then maps that thread ID to a Thread object. – Jeffrey Bosboom Feb 15 '15 at 15:20
  • 2
    I don't know about `currentThread`'s implementation details, but you can use a `ThreadLocal` if you want to use the same general mechanics in your own code. – duckstep Feb 15 '15 at 15:30
  • Very good question. In particular, is the object returned by _currentThread()_ always the same as the `Thread` object used to start the **thread**? Can it create two `Thread` objects for the same **thread**? Can a native function create a **thread** and invoke Java code? What `Thread` object will be returned for such **thread**? – 18446744073709551615 May 16 '16 at 15:28

1 Answers1

12
(basically a reference to 'this' thread)

There are no this references involved here.

You are mixing up a thread as a native resource, meaning the thread of execution; and Thread, which is a Java class. Thread code does not run "within" the Thread instance, that instance is just your handle into Java's thread control. Much like a File instance is not a file.

So, Thread.currentThread() is a way for you to retrieve the instance of Thread in charge of the thread-of-execution inside which the method is called. How exactly Java does this is an implementation detail which should not be your concern unless you are exploring the details of a particular JVM implementation.

Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436
  • It's not a perfect analogy, as a File instance is a path that might resolve to multiple actual OS-level files during its lifetime, while a Thread instance only represents a single thread during its lifetime. But the idea of Thread instances as handles is sound. – Jeffrey Bosboom Feb 15 '15 at 15:30
  • @JeffreyBosboom The mismatch between the lifecycle of `Thread` and the underlying thread makes this analogy stronger, though. `Thread` can (and does) exist without the underlying thread of execution---and could in fact easily represent different OS-level threads at different times (that is actually beyond the reach of the specification). – Marko Topolnik Feb 15 '15 at 15:32
  • @Marko Lets say I am exploring the details here, could you help me finding the source of currentThread() method ? I'd really like to see what is exactly going on inside this method. – maximus335 Feb 15 '15 at 16:06
  • You'll have to download the OpenJDK source code and search. – Marko Topolnik Feb 15 '15 at 17:07
  • 6
    `Thread.currentThread()` is a native method in OpenJDK. I haven't tried to find the C source code, but here's how I'd do it: I'd have a table at a fixed memory location with information about all of the thread stacks. That information would include the address of the base of the stack, the maximum size of the stack, and the ID of the `Thread` object associated with the stack. `Thread.currentThread()` would only have to take the address of any local variable in its activation record, and then consult the table to figure out which stack it belongs to, and therefore, which `Thread` to return. – Solomon Slow Feb 15 '15 at 23:54
  • 2
    It's not completely accurate to say that "no this references involved" since `this == Thread.currentThread()` holds true in some cases. `Thread.currentThread()` may return the instances you've once created and have some control over, or other `Thread` objects that have been created for you. – Andrew Tobilko Sep 03 '19 at 12:30