In Java concurrency, which statement about wait()/notify() scheduling and resumption is actually true?

Introduction / Context:
This question examines the precise semantics of the Java Object monitor methods wait(), notify(), and notifyAll(). Many beginners assume a deterministic “notify wakes one waiter and it runs immediately” model. In reality, the resumption of a waiting thread is neither immediate nor guaranteed; scheduling, monitor re-acquisition, and even spurious wakeups complicate the picture.

Given Data / Assumptions:

• One or more threads may be waiting (via wait()) on the same monitor object.
• Another thread may invoke notify() or notifyAll() while holding that object’s monitor (inside a synchronized block/method).
• Threads may compete to re-acquire the monitor after being notified.

Concept / Approach:
Calling notify() moves one arbitrary waiting thread from the wait set to the entry set for that monitor. That thread is merely made eligible to acquire the monitor again; it cannot proceed until the notifier eventually exits the synchronized region and releases the monitor. Even after release, the awakened thread competes with other threads and may starve. Additionally, spurious wakeups are permitted, which is why wait() must be used in a loop that re-checks the condition predicate.

Step-by-Step Solution:
A thread calls wait(): it releases the monitor and enters the wait set.Another thread calls notify(): one waiter is transferred to the entry set but is still blocked until the monitor is free.When the notifier exits synchronized, the monitor becomes available; the awakened thread competes with other contenders and may be delayed.Because of scheduling/starvation or logic errors, it is possible (though undesirable) that a particular waiting thread never proceeds.

Verification / Alternative check:
Run a test with multiple notifies and heavy contention: it is easy to observe the notified thread not running “immediately”, and under pathological contention, for a long time. Correct code always waits in a loop checking the condition.

Why Other Options Are Wrong:
Option A claims immediate resumption; this is false—monitor re-acquisition and scheduling interpose.
Option C guarantees definite, sole causality from notify(); not guaranteed—spurious wakeups and scheduling exist.
Option D claims FIFO fairness among waiters; Java does not guarantee any ordering for notified waiters.
Option E is incorrect because option B is correct.

Common Pitfalls:
Relying on notify() for ordering; forgetting to re-check the condition after wakeup; assuming immediate execution post-notify.

Final Answer:
If a thread is blocked in wait() and another thread calls notify() on the same object, it is still possible the waiting thread might never resume execution.