Strange java behavior of wait/notify

I've found strange behavior of java concurrency. See on the next code below:


    public class Test {
        static CountDownLatch latch = new CountDownLatch(1);
        public static void main(String[] args) throws UnsupportedEncodingException, InterruptedException {
            final Thread t = new MyThread();
            t.start();
            synchronized (t) {
                latch.countDown();
                System.out.println("got to sleep");
                t.wait();
                System.out.println("wake up");
            }
        }

        static class MyThread extends Thread {
            @Override
            public void run() {
                try {
                    latch.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (this) {
                    System.out.println("inside run");
    //                notifyAll();
                }
            }
        }
    }

In my point of view this code should be hang up and wait forever, but code is finished without any problem with next out in console:

got to sleep
inside run
wake up

I've tried to find some information about notifying locks if thread is died, but was lack in it. Also I've not find any information in java specification.

But if I've tried to lock on some other object (not on the thread object) it was work fine as I expected.


It's because you're waiting on a Thread instance. Thread uses wait / notify / notifyAll internally, so you shouldn't do that yourself as well - you'll confuse Thread , and Thread will confuse you. In particular, when a thread exits, it calls this.notifyAll() .

From the documentation of Thread.join :

This implementation uses a loop of this.wait calls conditioned on this.isAlive . As a thread terminates the this.notifyAll method is invoked. It is recommended that applications not use wait , notify , or notifyAll on Thread instances.

In general, try to lock and wait for objects which nothing else can interact with. That way you can reason about the concurrency-related operations which exist on the object, because they're very limited. As soon as arbitrary code can synchronize on the object (and call wait/notify etc) it's hard to prove that your code is correct. That's why you'll often see something like:

public class Foo {
    private final Object lock = new Object();

    ... code which uses synchronized(lock) ...
}

As Jon Skeet writes it is bad idea to synchronize on Thread object, use another one:

public class Test {
    static CountDownLatch latch = new CountDownLatch(1);
    static final Object sync = new Object();

    public static void main(String[] args) throws UnsupportedEncodingException, InterruptedException {
        final Thread t = new MyThread();
        t.start();
        synchronized (sync) {
            latch.countDown();
            System.out.println("got to sleep");
            sync.wait();
            System.out.println("wake up");
        }
    }
}

static class MyThread extends Thread {
    @Override
    public void run() {
        try {
            latch.await();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        synchronized (sync) {
            System.out.println("inside run");
            //sync.notifyAll();
        }
    }
}

Now this code will never ending until you uncomment sync.notifyAll();

链接地址: http://www.djcxy.com/p/91972.html

上一篇: 散列图并发问题

下一篇: wait / notify的奇怪java行为