Java Multi-Threading 7: Deadlock

Objective

Deadlocks write a separate article because it is a serious problem that must be brought to the attention of the individual. This is not an exaggeration of the risk of a deadlock, although the lock is usually held for a short time, the application as a commercial product may perform billions of times a day to acquire lock-and-release locks, as long as there is an error in these billions of operations, which can cause a deadlock in the program. And even through stress tests it is impossible to find out all potential deadlocks.

Dead lock

A classic multithreading problem.

When a thread holds a lock forever, and other threads try to get the lock, then they will always be blocked, as we all know. If thread a holds the lock L and wants to get the lock m, thread B holds the lock m and wants to get the lock L, then these two threads will wait forever, and this is the simplest form of deadlock.

Monitoring deadlocks and recovering from deadlocks are considered in the design of the database system, and if a database detects a deadlock in a set of things, it will choose a victim and abandon the thing. The Java Virtual machine solves the deadlock problem with no database so powerful, when a set of Java threads Deadlock, the two threads can never be reused, and since two threads hold two locks, the two synchronization code/code blocks can no longer run----unless the application is terminated and restarted.

Deadlock is a design bug, the problem is more obscure. However, the effects of deadlocks are rarely immediately apparent, and a class may have a deadlock, which does not mean that deadlocks occur every time, which is just a sign of possible. When a deadlock occurs, it is often in the worst case----a high load.

Here is a simple code that generates a deadlock and shows how to parse it as a deadlock:

Note that there must be "Thread.Sleep (2000)" To let the thread sleep, or one thread is running, another thread is not running, and the first running thread is likely to have two locks in a row. Write two threads to call them separately:

As for the result, no result, no statement will print, because the deadlock. Here's how to position the deadlock problem:

1, JPS get PID of current Java Virtual machine process

2, jstack print stack. Jstack the end of the printed content has actually been reported to have found a deadlock, but because we are analyzing the cause of the deadlock, rather than directly get here a deadlock conclusion, so forget it, look at the front part

First explain the meaning of each part, take "Thread-1" as an example:

(1) "Thread-1" indicates the thread name

(2) "prio=6" indicates thread priority

(3) "TID=00000000497CEC00" indicates the thread ID

(4) nid=0x219c

The thread corresponds to the local thread ID, which is highlighted below. Because Java threads are run by local threads attached to Java virtual machines, the local thread is actually executing Java thread code, and only the local thread is the real thread entity. Java code creates a thread, and the virtual machine creates a corresponding local thread at run time, and the local thread is the real thread entity. Linux environment can use "top-h-p JVM Process id" to see the JVM process under the local thread (also known as LWP) information, note that the local thread is in decimal notation, nid is in 16 binary notation, the conversion is good, The 0x219c corresponding local thread ID should be 8604.

(5) "[0x000000004a3bf000. 0X000000004A3BF790] "Indicates the memory address occupied by the thread

(6) "Java.lang.Thread.State:BLOCKED" indicates the state of the thread

Explain the meaning of each part, see Thread-1 in blocked state, Thread-0 in blocked state. Analyze these two threads:

(1) Thread-1 obtained the lock 0x000000003416a4e8, waiting for the lock 0x000000003416a4d8

(2) Thread-0 obtained the lock 0x000000003416a4d8, waiting for the lock 0x000000003416a4e8

Since two threads are waiting to acquire the lock held by each other, they are waiting forever.

3, note the use of Eclipse/myeclipse, this program if you do not click on the console above the red box to terminate off it, but the right button->run as->1 Java application, the process will always exist, You can use the Taskkill command to terminate a process that is not terminate:

Ways to avoid deadlocks

Now that you may have a deadlock, then let's talk about how to avoid deadlocks.

1, so that the program can only get one lock at a time. Of course, in a multithreaded environment, this situation is usually not realistic

2, design to consider the sequence of locks, minimize the number of locked-in interaction

3, since the creation of the deadlock is two threads infinite waiting for the other side of the lock, then as long as the waiting time there is a limit not good. Of course synchronized does not have this function, but we can use the Trylock method in the lock class to try to acquire the lock, this method can specify a time-out period and return a failure message after waiting for the time limit.

Java Multi-Threading 7: Deadlock