Is it ok to use the intrinsic lock of a Thread object in Java?

Question

So in Java I know that you can use the so-called "intrinsic lock" of objects to create mutual exclusion regions as well as to ensure memory visibility. Java makes it particularly easy to implicitly lock on the intrinsic lock of the this object with some syntax sugar like:

public class Foo{
    public synchronized doFoo(){
        //doFoo is executed in an implicit synchronized block
        //on the 'this' object
    }
}

This is understandable and accepted practice for guarding the member fields of many objects. What I don't know is whether the above is okay when the object being locked on is a Thread object. E.g., are there any reasons to avoid the following?

public class Bar extends Thread{ //notice the 'extends Thread' here
    public synchronized doBar(){
        //doBar is executed in an implicit synchronized block
        //on the 'this' object
    }
}

For now, I'm going to stick with something I know is more safe, e.g.:

public class Baz extends Thread{ //notice the 'extends Thread' here
    private final Object explicitLockObject = new Object();

    public doBaz(){
        synchronized(explicitLockObject){
            //doBaz impl
        }
    }
}

My concerns would be two-fold with option #2 (the Bar example):

1. Is there existing jvm code or Java convention regarding synchronizing on the Thread itself that might conflict with such a locking policy?
2. Locking on this generally implies that access of that object should always be guarded by that object's intrinsic lock. In the case of a Bar thread, that means we're implying that any time you touch a Bar thread, you should synchronize on the instance. That seems like it could end up causing some other thread to block unnecessarily (or even dangerously) until Bar completes/exits.

Are the above valid concerns? I feel like I need a Brian Goetz beacon for this one :-)

Answer 1

... are there any reasons to avoid [locking on a Thread instance]?

So if you look at the Thread class, you can see that there are are a number of instance synchronized methods. They include:

• start()
• stop() (deprecated)
• join(long) (which is called from join())
• join(long, int)

That seems like it could end up causing some other thread to block unnecessarily (or even dangerously) until Bar completes/exits.

Right, so anyone calling the above methods would block with other synchronized methods. Obviously only the join(...) methods would actual be a problem and they should't return until the Thread finishes anyway.

As stated in the javadocs for Thread.join(...):

As a thread terminates the this.notifyAll() method is invoked. It is recommended that applications not use wait(), notify(), or notifyAll() on Thread instances.

I see no warnings about synchronized anywhere in the Thread source.

Also quick glance through ThreadPoolExecutor shows that it at least doesn't synchronize on the Runnable or Callable instances which would be pretty bad so at least with a standard ExecutorService you should be good.

So I guess the short answer is that although it maybe not recommended, in a pinch synchronizing on the Thread should work. As you mention, it would be better for you to implement Runnable and lock on it instead of extend Thread.

Hope this helps.