notify() vs notifyAll() in Java

The difference is pretty straightforward: notify wakes up one waiting thread, and notifyAll wakes up all of them. But here's where it gets interesting. With notify, you have zero control over which thread wakes up — the JVM just picks one arbitrarily. That thread will reacquire the lock and check its condition. If the condition's true, great, it proceeds. If not, it goes back to sleep. The problem happens when you've got different types of threads waiting for different things on the same object. Like in a producer-consumer setup, you've got producers waiting when the queue is full and consumers waiting when it's empty. If you use notify and a producer adds an item, you might accidentally wake up another producer instead of a consumer. That producer will check the queue, see it's still full, and go right back to sleep. Your notification got wasted, and the consumer that should've woken up is still asleep. In the worst case, this can leave eligible waiters asleep and prevent progress in an incorrectly designed protocol. That's why notifyAll is usually safer. It wakes up every waiting thread. They all compete for the lock, and each one checks its own condition. Only the threads whose conditions are true will proceed; the rest go back to wait. Yes, notifyAll has more overhead because more threads wake up, but the cost depends on waiter count and contention compared to the risk of a subtle notify bug. In production code, you'd typically use BlockingQueue or another concurrent utility that handles all this internally. But understanding this difference shows you know the low-level coordination primitives. I'd use notifyAll unless I could prove any selected waiter can make progress and any one of them could handle the notification.