Of course! This is a very common and important question in Java concurrency. The short answer is:

You do not use wait() directly inside an if statement. You must use it inside a while loop.

Let's break down why this is so critical and how to do it correctly.

The Golden Rule of wait()

The fundamental rule for using wait() is:

Always call wait() inside a loop that checks the condition it is waiting for.

（图片来源网络，侵删）

The "Why": Spurious Wakeups

The primary reason for this rule is that a thread can be woken up from wait() for reasons other than the intended notify() or notifyAll(). These are called spurious wakeups.

According to the Java Language Specification (JLS), wait() can return "without any notification having been received." This is a rare, but possible, event. If your code relies on an if statement, a spurious wakeup will cause the thread to proceed incorrectly, assuming the condition has been met when it hasn't.

Example of INCORRECT Code (using if)

Imagine a simple scenario where a producer adds an item to a queue, and a consumer waits for an item to be available.

// INCORRECT - DO NOT USE
class Queue {
    private String item;
    private boolean itemAvailable = false;
    // Called by the Producer
    public void put(String item) {
        this.item = item;
        this.itemAvailable = true;
        System.out.println("Producer: Notifying a consumer.");
        notify(); // Wake up one waiting thread
    }
    // Called by the Consumer
    public String get() throws InterruptedException {
        // THE PROBLEM IS HERE
        if (!itemAvailable) { // <--- IF STATEMENT
            System.out.println("Consumer: Waiting for an item...");
            wait(); // This could return spuriously!
        }
        // If we get here, we assume itemAvailable is true
        String theItem = this.item;
        this.itemAvailable = false;
        return theItem;
    }
}

What could go wrong?

1. Consumer calls get(): The itemAvailable is false. The consumer calls wait() and goes to sleep.
2. Producer calls put(): The producer adds an item, sets itemAvailable to true, and calls notify(). This wakes up the consumer.
3. Consumer resumes: The consumer's lock is reacquired, and execution continues after the wait() call. It gets the item and everything works fine.

Now, let's introduce a spurious wakeup:

1. Consumer calls get(): The itemAvailable is false. The consumer calls wait() and goes to sleep.
2. Spurious Wakeup: For an unknown reason, the consumer's thread is woken up by the JVM, before the producer has even called put().
3. Consumer resumes: The consumer's lock is reacquired, and execution continues after the wait() call.
4. The Bug: The if condition (!itemAvailable) is still true! The code completely ignores this and proceeds to try and access this.item, which is null. This will likely result in a NullPointerException or incorrect behavior.

The Correct Way: Using a while Loop

To solve the spurious wakeup problem and handle other race conditions, you must re-check the condition inside a while loop after wait() returns.

Example of CORRECT Code (using while)

Here is the same Queue class, implemented correctly.

// CORRECT - ALWAYS USE A WHILE LOOP
class CorrectQueue {
    private String item;
    private boolean itemAvailable = false;
    // Called by the Producer
    public synchronized void put(String item) {
        // If an item is already available, wait until the consumer takes it
        while (itemAvailable) {
            try {
                wait(); // Producer can also wait if the queue is full
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
                return;
            }
        }
        this.item = item;
        this.itemAvailable = true;
        System.out.println("Producer: Produced '" + item + "'. Notifying consumer.");
        notify(); // Wake up one waiting thread (consumer or producer)
    }
    // Called by the Consumer
    public synchronized String get() throws InterruptedException {
        // THE FIX IS HERE - A WHILE LOOP
        while (!itemAvailable) { // <--- WHILE LOOP
            System.out.println("Consumer: Waiting for an item...");
            wait(); // This will re-check the condition after being notified or spuriously woken up
        }
        // If we get here, we are GUARANTEED that itemAvailable is true
        String theItem = this.item;
        this.itemAvailable = false;
        System.out.println("Consumer: Consumed '" + theItem + "'. Notifying producer.");
        notify(); // Wake up the producer in case it was waiting
        return theItem;
    }
}

Why this works:

1. Consumer calls get(): itemAvailable is false. The consumer enters the while loop and calls wait().
2. Spurious Wakeup: The consumer's thread is woken up spuriously.
3. Consumer re-enters the loop: The lock is reacquired, and the while condition is re-evaluated.
   • !itemAvailable is still true.
   • The condition is met, so the thread calls wait() again and goes back to sleep.
4. Producer calls put(): The producer sets itemAvailable to true and calls notify(). This wakes up the consumer.
5. Consumer re-enters the loop (again): The lock is reacquired, and the while condition is re-evaluated.
   • !itemAvailable is now false.
   • The condition is not met, so the loop exits.
6. Safe Execution: The code proceeds to safely get the item. The condition has been verified one last time right before the critical section.

Summary: if vs. while for wait()

Key Takeaways

1. Synchronization is Required: The thread that calls wait() must own the object's lock. This means wait() and notify()/notifyAll() must be called from within a synchronized method or block.
2. Always Use while: Protect yourself from spurious wakeups and race conditions by always checking the waiting condition in a while loop.
3. Check the Condition: The condition in the while loop should be the exact opposite of the condition that made you call wait() in the first place.