Helping ordinary people create extraordinary websites!
HOME TUTORIALS SCRIPTS WEB HOSTING BLOG FORUM
Get Our Newsletter
Your Email:

Eye on performance: Wait leaks

By Jack Shirazi & Kirk Pepperdine
2005-04-28


Wait Leaks

One class of race conditions, which we call a wait leak, recently came to our attention. The basic issue is that when you use the wait/notify idiom, you typically have one or more threads blocked in the wait() call, waiting for another thread to notify it that some condition has become true, so it can exit the wait() call and carry on processing. The notifying thread calls notify() or notifyAll() to signal that waiting threads can now wake up and carry on processing.

This has the obvious potential for a race condition, but it is one we haven't seen in practice until recently. What happens if you enter the wait state to wait for a particular resource to become available, but another thread calls notify() just before you enter the wait state? The result is a thread stuck in the wait state, even though the resource is available.

Of course there are solutions to avoid this scenario-- after all, it is a bug like other bugs. Clearly you want to be more careful that you check whether the resource is available, in an atomic manner, before entering the wait state. More specifically, you should check whether the resource is available while inside the synchronized block, and not enter the wait if the resource is available (which is the recommended, but potentially less scalable solution), or you could use some of the more sophisticated synchronization classes and associated techniques available as part of JDK 5.0 (see Resources).

Wait leaks are certainly a bug, but what we want to look at here is not the solution to the problem, but a way to identify the problem. In a complex application with tens or hundreds of threads, it can be difficult to spot a wait leak unless you have seen the symptoms before. Unlike a deadlock, there is no obvious telltale evidence like two threads waiting on each other's locked monitors. Instead, there are just lots of threads sitting in Object.wait() calls, which can otherwise be quite normal for many applications.

Tutorial Pages:
» Gain a Better Understanding of this Curious Race Condition
» Wait Leaks
» Simulating a Wait Leak
» Spotting a Wait Leak
» The Final Word
» Resources


First published by IBM developerWorks


 | Bookmark
Related Tutorials:
» All about JAXP, Part 1
» Make Database Queries Without the Database
» Load List Values for Improved Efficiency
» 2 Ways To Implement Session Tracking
» A Simple Way to Read an XML File in Java
» Develop Aspect-Oriented Java Applications with Eclipse and AJDT