Question

I wrote a test app that should never stop. It issues t.wait() (t is a Thread object), but I never call notify. Why does this code end?
Despite the main thread synchronizing on t, the spawned thread runs, so it doesn’t lock this object.

public class ThreadWait {
    public static void main(String sArgs[]) throws InterruptedException {
        System.out.println("hello");
        Thread t = new MyThread();
        synchronized (t) {
            t.start();
            Thread.sleep(5000);
            t.wait();
            java.lang.System.out.println("main done");
        }
    }
}

class MyThread extends Thread {
    public void run() {
        for (int i = 1; i <= 5; i++) {
            java.lang.System.out.println("" + i);
            try {
                Thread.sleep(500);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }
        }
    }
}

The result is that the main thread waits 5 seconds and during this time worker gives its output. Then after 5 seconds are finished, the program exits. t.wait() does not wait. If the main thread wouldn’t sleep for 5 seconds (commenting this line), then t.wait() would actually wait until the worker finishes. Of course, join() is a method to use here, but, unexpectedly, wait() does the same thing as join(). Why?

Maybe the JVM sees that, since only one thread is running, there is no chance to notify the main thread and solves the deadlock. If this is true, is it a documented feature?

I’m testing on Windows XP, Java 6.

Answer 1

You’re waiting on a Thread – and while most objects aren’t implicitly notified, a Thread object is notified when the thread terminates. It’s documented somewhere (I’m looking for it…) that you should not use wait/notify on Thread objects, as that’s done internally.

This is a good example of why it’s best practice to use a “private” object for synchronization (and wait/notify) – something which only your code knows about. I usually use something like:

private final Object lock = new Object();

(In general, however, it’s cleaner to use some of the higher-level abstractions provided by java.util.concurrent if you can. As noted in comments, it’s also a good idea to implement Runnable rather than extending Thread yourself.)