Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API
We say that a set of processes or threads is deadlocked when each thread is waiting for an event that only another process in the set can cause. Another way to illustrate a deadlock is to build a directed graph whose vertices are threads or processes and whose edges represent the "is-waiting-for" relation. If this graph contains a cycle, the system is deadlocked. Unless the system is designed to recover from deadlocks, a deadlock causes the program or system to hang.
Deadlocks can occur in Java because the synchronized keyword causes the executing thread to block while waiting for the lock, or monitor, associated with the specified object.
Since the thread might already hold locks associated with other objects, two threads could each be waiting for the other to
release a lock; in such a case, they will end up waiting forever. The following example shows a set of methods that have the
potential for deadlock. Both methods acquire locks on two lock objects, cacheLock and tableLock, before they proceed. In this example, the objects acting as locks are global (static) variables, a common technique for
simplifying application-locking behavior by performing locking at a coarser level of granularity:
Listing 1. A potential synchronization deadlock
public static Object cacheLock = new Object();
public static Object tableLock = new Object();
...
public void oneMethod() {
synchronized (cacheLock) {
synchronized (tableLock) {
doSomething();
}
}
}
public void anotherMethod() {
synchronized (tableLock) {
synchronized (cacheLock) {
doSomethingElse();
}
}
}
Now, imagine that thread A calls oneMethod() while thread B simultaneously calls anotherMethod(). Imagine further that thread A acquires the lock on cacheLock, and, at the same time, thread B acquires the lock on tableLock. Now the threads are deadlocked: neither thread will give up its lock until it acquires the other lock, but neither will
be able to acquire the other lock until the other thread gives it up. When a Java program deadlocks, the deadlocking threads
simply wait forever. While other threads might continue running, you will eventually have to kill the program, restart it,
and hope that it doesn't deadlock again.
Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq
![]()
Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq