A simple scenario using wait() and notify() in java

The wait() and notify() methods are designed to provide a mechanism to allow a thread to block until a specific condition is met. For this I assume you're wanting to write a blocking queue implementation, where you have some fixed size backing-store of elements.

The first thing you have to do is to identify the conditions that you want the methods to wait for. In this case, you will want the put() method to block until there is free space in the store, and you will want the take() method to block until there is some element to return.

public class BlockingQueue<T> {    private Queue<T> queue = new LinkedList<T>();    private int capacity;    public BlockingQueue(int capacity) {        this.capacity = capacity;    }    public synchronized void put(T element) throws InterruptedException {        while(queue.size() == capacity) {            wait();        }        queue.add(element);        notify(); // notifyAll() for multiple producer/consumer threads    }    public synchronized T take() throws InterruptedException {        while(queue.isEmpty()) {            wait();        }        T item = queue.remove();        notify(); // notifyAll() for multiple producer/consumer threads        return item;    }}

There are a few things to note about the way in which you must use the wait and notify mechanisms.

Firstly, you need to ensure that any calls to wait() or notify() are within a synchronized region of code (with the wait() and notify() calls being synchronized on the same object). The reason for this (other than the standard thread safety concerns) is due to something known as a missed signal.

An example of this, is that a thread may call put() when the queue happens to be full, it then checks the condition, sees that the queue is full, however before it can block another thread is scheduled. This second thread then take()'s an element from the queue, and notifies the waiting threads that the queue is no longer full. Because the first thread has already checked the condition however, it will simply call wait() after being re-scheduled, even though it could make progress.

By synchronizing on a shared object, you can ensure that this problem does not occur, as the second thread's take() call will not be able to make progress until the first thread has actually blocked.

Secondly, you need to put the condition you are checking in a while loop, rather than an if statement, due to a problem known as spurious wake-ups. This is where a waiting thread can sometimes be re-activated without notify() being called. Putting this check in a while loop will ensure that if a spurious wake-up occurs, the condition will be re-checked, and the thread will call wait() again.

As some of the other answers have mentioned, Java 1.5 introduced a new concurrency library (in the java.util.concurrent package) which was designed to provide a higher level abstraction over the wait/notify mechanism. Using these new features, you could rewrite the original example like so:

public class BlockingQueue<T> {    private Queue<T> queue = new LinkedList<T>();    private int capacity;    private Lock lock = new ReentrantLock();    private Condition notFull = lock.newCondition();    private Condition notEmpty = lock.newCondition();    public BlockingQueue(int capacity) {        this.capacity = capacity;    }    public void put(T element) throws InterruptedException {        lock.lock();        try {            while(queue.size() == capacity) {                notFull.await();            }            queue.add(element);            notEmpty.signal();        } finally {            lock.unlock();        }    }    public T take() throws InterruptedException {        lock.lock();        try {            while(queue.isEmpty()) {                notEmpty.await();            }            T item = queue.remove();            notFull.signal();            return item;        } finally {            lock.unlock();        }    }}

Of course if you actually need a blocking queue, then you should use an implementation of the BlockingQueue interface.

Also, for stuff like this I'd highly recommend Java Concurrency in Practice, as it covers everything you could want to know about concurrency related problems and solutions.

Not a queue example, but extremely simple :)

class MyHouse {    private boolean pizzaArrived = false;    public void eatPizza(){        synchronized(this){            while(!pizzaArrived){                wait();            }        }        System.out.println("yumyum..");    }    public void pizzaGuy(){        synchronized(this){             this.pizzaArrived = true;             notifyAll();        }    }}

Some important points:
1) NEVER do

 if(!pizzaArrived){     wait(); }

Always use while(condition), because

• a) threads can sporadically awakefrom waiting state without beingnotified by anyone. (even when thepizza guy didn't ring the chime,somebody would decide try eating thepizza.).
• b) You should check for thecondition again after acquiring thesynchronized lock. Let's say pizzadon't last forever. You awake,line-up for the pizza, but it's notenough for everybody. If you don'tcheck, you might eat paper! :)(probably better example would bewhile(!pizzaExists){ wait(); }.

2) You must hold the lock (synchronized) before invoking wait/nofity. Threads also have to acquire lock before waking.

3) Try to avoid acquiring any lock within your synchronized block and strive to not invoke alien methods (methods you don't know for sure what they are doing). If you have to, make sure to take measures to avoid deadlocks.

4) Be careful with notify(). Stick with notifyAll() until you know what you are doing.

5)Last, but not least, read Java Concurrency in Practice!

Even though you asked for wait() and notify() specifically, I feel that this quote is still important enough:

Josh Bloch, Effective Java 2nd Edition, Item 69: Prefer concurrency utilities to wait and notify (emphasis his):

Given the difficulty of using wait and notify correctly, you should use the higher-level concurrency utilities instead [...] using wait and notify directly is like programming in "concurrency assembly language", as compared to the higher-level language provided by java.util.concurrent. There is seldom, if ever, reason to use wait and notify in new code.