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 will never be used again, and because two threads hold two locks, the two synchronized parts of the code can no longer run----unless terminated and restarted the application.
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:
Public classdeadlock{Private FinalObject left =NewObject (); Private FinalObject right =NewObject (); Public voidLeftRight ()throwsException {synchronized(left) {Thread.Sleep (2000); synchronized(right) {System.out.println ("LeftRight end!"); } } } Public voidRightleft ()throwsException {synchronized(right) {Thread.Sleep (2000); synchronized(left) {System.out.println ("Rightleft end!"); } } }}
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:
public class Thread0 extends thread{ private DeadLock DL; Public Thread0 (DeadLock dl) { this.dl = dl; } public void Run () { try {dl.leftright ();} catch (Exception e) {e.printstacktrace ();}}}
public class Thread0 extends thread{ private DeadLock DL; Public Thread0 (DeadLock dl) { this.dl = dl; } public void Run () { try {dl.leftright ();} catch (Exception e) {e.printstacktrace ();}}}
Write a main function call:
public static void main (string[] args) { DeadLock dl = new DeadLock (); Thread0 t0 = new Thread0 (DL); Thread1 T1 = new Thread1 (DL); T0.start (); T1.start ();}
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 print the end of the content has actually been reported found a deadlock, forget it
Thread-1 is in blocked state, Thread-0 is 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