Listing 1's methods have the potential for deadlock because each method acquires the two locks in a different order. Inconsistent lock ordering causes deadlocksįortunately, we can impose a relatively simple requirement on lock acquisition that can prevent synchronization deadlocks.
#Deadlock in java code#
Deadlocks resemble time bombs waiting to explode in our code when they do, our programs simply hang. Code can have the potential for deadlock, like Listing 1, but not exhibit deadlock until some combination of random and nonrandom events occur, such as the program being subjected to a certain load level, run on a certain hardware configuration, or exposed to a certain mix of user actions and environmental conditions. Testing for deadlocks is difficult, as deadlocks depend on timing, load, and environment, and thus might happen infrequently or only under certain circumstances. While other threads might continue running, you will eventually have to kill the program, restart it, and hope that it doesn't deadlock again. When a Java program deadlocks, the deadlocking threads simply wait forever. 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. Imagine further that thread A acquires the lock on cacheLock, and, at the same time, thread B acquires the lock on tableLock. Now, imagine that thread A calls oneMethod() while thread B simultaneously calls anotherMethod(). Public static Object tableLock = new Object() A potential synchronization deadlock public static Object cacheLock = new Object() 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: Both methods acquire locks on two lock objects, cacheLock and tableLock, before they proceed. The following example shows a set of methods that have the potential for deadlock. 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. Synchronization deadlocks in Java programsĭeadlocks 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.
Unless the system is designed to recover from deadlocks, a deadlock causes the program or system to hang. If this graph contains a cycle, the system is deadlocked.
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. 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. However, another risk is associated with excessive synchronization: deadlock. So it seems that there is now less reason than ever to avoid synchronizing. Additionally, while synchronization carries a performance penalty, the penalty associated with uncontended synchronization is not as great as some sources have suggested, and has reduced steadily with each successive JVM implementation. Here is a sample deadlock that the findDeadlockedThreads method mentioned earlier won't get: import .In my earlier article " Double-Checked Locking: Clever, but Broken" ( JavaWorld, February 2001), I described how several common techniques for avoiding synchronization are in fact unsafe, and recommended a strategy of "When in doubt, synchronize." In general, you should synchronize whenever you are reading any variable that might have been previously written by a different thread, or whenever you are writing any variable that might be subsequently read by another thread. The thread might even have thrown an exception and died leaving the read count non-zero.
What makes it especially hard to debug is that there is no record of who has entered a read lock. That is where you have a ReentrantReadWriteLock and one thread grabs the read lock and then (say) tries to enter a monitor held by some other thread that is also waiting to grab the write lock. Note that there is a type of deadlock using the concurrent package that is very hard to debug.
0 kommentar(er)
