Java Multithreading Foundation Summary One: synchronized (1)

Recently wrote about the small application of concurrency, only to find that it is really good to face the Java multithreading. There was no deep mastery before, and it was so laborious to use. As one of the few important difficulties in J2SE, multithreading application has always been my attitude of awe to avoid, but through some examples to master some simple application. This time will take a little more time to grasp, there is a need to write down I will share in this way and deepen understanding.

First of all, this article only involves the basic knowledge of the collation, for and the contract java.util.concurrent within the thread pool and lock I will look at the situation in the summary after writing something. We are familiar with the concept of the process, which is application-level isolation, where processes between different applications rarely share any resources. threads, however, can be said to be isolated within the application, a relatively low level of isolation. A process can have multiple threads, and the content that is isolated between them roughly includes: a. Its own stack, B. program counter, c. local variables; the content of the shared application is roughly as follows: A. Memory, B. File handle, C. process status, etc. Thread is not the concept of Java itself, it is the concept of the underlying operating system. Java as an application language to promote the operation of the thread through the API to application development support, but in the concurrency of the support is not so good.

Java at design time, each object has an implicit lock, the use of this lock is through the Synchronized keyword to use explicitly. After JDK5.0 reference to Java.util.concurrent.ReentrantLock as a synchronized option, and condition can be a conditional locking mechanism to manage concurrent threads, after the summary of the introduction. When it comes to synchronized, most beginners know that the object's Wait (), notify (), Notifyall () are matched and used, but why is it possible to use these methods of objects in sync (or else throw illegalmonitorstateexception)?

I think because there is no synchronized to make an object's implicit lock work, then the method or the thread within the method block may have multiple at the same time, assuming that wait () is available, it will add all of these threads to the waiting set to be awakened so that there is never any extra thread to wake them up. Each object manages a thread that calls its wait (), notify (), so that other objects cannot help even if they want to help. The result is that multithreading never accomplishes multitasking, based on the Java design that must be used in conjunction with synchronized, so that the thread that gets an implicit lock is only one at a time, when this thread is thrown by the object's wait () into the waiting set, The thread frees the object of an implicit lock waiting for the opportunity to be awakened, a design that greatly reduces the deadlock. In addition, multiple methods or method blocks under implicit locking of the same object can allow multiple threads to wait and notify in different methods without locking, and severe competitive conditions make deadlocks easy. So the Java designers are trying to solve these problems through the monitor object pattern, each of which is monitored by monitor for the threads that have their right to use.

But synchronized's way of getting an implicit lock is inherently problematic: a. Cannot break the thread that is trying to acquire the lock, B. Cannot set timeout when attempting to acquire a lock, C. Only one condition per lock is too small. The JDK5 scheme mentioned earlier in the design of the last item can be remedied, a reentrantlock can have multiple condition, each condition manages to get the object lock to meet the condition of the thread, through await (), Signalall () Keep the thread about condition itself running, or drop some threads instead of waking them all, and so on. But for the extremes of the first two there will be deadlocks. The following example:

Java code

class　DeadLockSample{
　　 public　final　Object　lock1　=　new　Object();
　　 public　final　Object　lock2　=　new　Object();

　　 public　void　methodOne(){
　　　　 synchronized(lock1){
　　　　　 ...
　　　　　 synchronized(lock2){...}
　　　　 }
　　 }

　　 public　void　methodTwo(){
　　　　 synchronized(lock2){
　　 ...
　　　　　 synchronized(lock1){...}
　　　　 }
　　 }
}

Scenario: Thread A calls MethodOne (), obtains the implicit lock of the LOCK1, obtains Lock2 's implicit lock when the line B enters the run, invokes Methodtwo (), and obtains the Lock2 implicit lock, at which point thread a waits for thread B to hand over the lock2. Thread B waits for the Lock1 to enter the method block, and the deadlock is created.