Difference between methods from Thread class and methods used with Thread.currentThread()?

Question

I want to start with doc from method currentThread():

Returns a reference to the currently executing thread object.

@return the currently executing thread.

Now knowing this, it makes sense that methods such as join(), isAlive(), getName(), isInterrupted() etc. are called like this for example Thread.currentThread().join.

My question is how we don't need currentThread prefix to call methods such as sleep(), yield(), interrupted() etc? How can static call for example Thread.sleep() know exactly what thread instance are we 'targeting' when there is no instance?

@WJS I know that honestly. But why? Couldn't they make methods join, isAlive, getName.. static as well as they did for those 'last 3 methods'? — Stefan
– Stefan, Commented Sep 17, 2020 at 1:11
Nope. For example. getName() returns the name of the current thread. But if getName were static, it wouldn't know which thread to return the name of. If some information is required from the current thread instance, then you need an instance field. For something that is simply shared (like sleep which is independent of an instance it can be static. — WJS
– WJS, Commented Sep 17, 2020 at 1:13
Makes sense :) But how would it know which thread to sleep for example? Remember sleep is static as well. — Stefan
– Stefan, Commented Sep 17, 2020 at 1:14
You're sleeping in the instance that you are presently in at the time. — WJS
– WJS, Commented Sep 17, 2020 at 1:15

Cameron Skinner · Accepted Answer · 2020-09-17 01:27:56Z

How can static call for example Thread.sleep() know exactly what thread instance are we 'targeting' when there is no instance?

They target the currently executing thread.

From the docs for Thread:

Causes the currently executing thread to sleep

The documentation for yield and interrupted etc also mention that they affect the current thread.

Regarding the comments about join, getName etc:

It doesn't make sense to make join static. If you did, the only thread you could join would be the current thread, which would immediately deadlock. You would be asking the current thread to wait for itself. join has to be non-static so you can tell it which thread to wait for (OK, you could have static join(Thread threadToJoin) but that's pretty cumbersome).

Sleep, and yield only make sense statically - you would never tell another thread to sleep or yield (you don't know what the other thread is doing - it might not be in a sensible state to sleep or yield). You only ever want to put yourself to sleep.

The other methods you mention in the comments could conceivably have static variants, but it makes more sense for them to be non-static because they provide information about the specific Thread object they are called on. You may notice that interrupted and isInterrupted are static and non-static, respectively, so there are cases where it makes sense to provide both. Is it worth having a static getCurrentThreadName() method? Probably not. We don't look for thread names very often, but checking for interruption is a very common operation so the convenience of not having to say Thread.currentThread().isInterrupted() outweighs the cost of maintaining two methods.

Solomon Slow · Accepted Answer · 2020-09-17 14:00:14Z

why is for example Thread.sleep() written and not Thread.currentThread().sleep()

Because sleep() is not something that one thread should be able to do to a different thread.

Thread.currentThread() returns a reference to an instance of the Thread class. It's a special instance from the caller's point of view (i.e., it happens to be the Thread that called the function,) but from the language point of view, there's nothing special about it at all. It's just a thread.

That means, if you can call Thread.currentThread().foo(), then you can call someOtherThread.foo().

Even if you were allowed to call someOtherThread.sleep(), it would be a very bad idea. That's why they made sleep() a static method that implicitly operates on the calling thread.

My question is how we don't need currentThread prefix ...

OK, this is just my two cents worth, but if you think of currentThread() as some kind of a prefix, then I would advise you to spend more time learning the basics of the Java language before you dive into writing multi-threaded programs.

Collectives™ on Stack Overflow

Difference between methods from Thread class and methods used with Thread.currentThread()?

2 Answers 2

Comments

Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

Comments

Comments

Related