Java Multithreaded Learning notes--some understanding of multithreading data synchronization from the Java JVM

We know that in multithreaded programming, a large part of our content is to solve the problem of resource synchronization between threads and collaboration between threads. Synchronization between threads, popular we understand as go round, in the limited circumstances of porridge, we how to prevent everyone in order to drink porridge, do not have to drink. Threading collaboration, we can understand that when we are in the hospital, we have to register before the doctor. Now there are many patients in the hospital queue, how to coordinate the patients are orderly first registered, after the doctor. The focus of this article is not here, nor this can be analyzed at once, we first from the Java JVM perspective to understand some aspects of multithreading.

We know that data is synchronized between multiple threads, and we do this by locking. How are locks between threads reflected? First, we look at what kind of data the Java thread needs to handle. Let's briefly introduce the Java thread memory allocation.

First, the smallest unit of data allocation for a Java program is a process, in which there is at least one main thread that can share data between threads. However, each of our threads also has its own thread stacks, so the Java thread does not need to consider the private data of each thread's private line Cheng. such as: Non-synchronous methods of the objects of the class or (temporary variables defined in the code block), they allocate memory in the thread stack, because they are the temporary variables defined in the method, other objects simply cannot get its memory, so there is no need to consider the synchronization of such numbers.

We briefly summarize that at least the following two types of data are accessed by multiple threads, and we need to consider data synchronization: 1. An instance of the class that exists in the heap; 2. Class variables in the method scope of the class.

So, when we have multiple threads that are likely to have access to both types of data at the same time, we need to add locks to them, first-come-first-served, with only a single access. By learning we know that the lock of an object in Java is an exclusive lock, and each class and object will have a corresponding lock. In our usual programming, the usual way to trigger a lock is to synchronize the shared resources in a mutually exclusive way, so that access to the block of code is allowed only one object at a time. In Java syntax, there are at least two ways to synchronize code blocks to synchronize shared resources, such as the synchronized and Reentrantlock locking methods.

　　A little understanding of synchronized and Reentrantlock　　

Discussion on performance of synchronized and reentrantlock many articles are divided, there is a saying, javase The Reentrantlock design in Java.util.concurrent is the alternative to synchronized, with better performance (http://www.ibm.com/developerworks/cn/java/ j-jtp10264/index.html), there is also a claim that, after JDK 1.6, two have no difference in performance (Java Concurrency in Pratice). But a little, we must be able to unify the understanding, the use of Reetrantlock, in the design to compensate for the synchronized existence of some shortcomings, at least in the design of two points we can see Reetrantlock to synchronized improvement:

1.ReetrantLock can easily capture the lock code block exception, the code is as follows:

New Reentrantlock ();  ...  Lock.lock ();   Try {      //finally  {      lock.unlock ();  }  

2.ReetrantLock implements an interrupt lock mechanism, synchronized locking threads may wait indefinitely, even if those threads that are consuming resources are deadlocked, the resources waiting for them will continue to wait. However, Reentrantlock can choose to discard the wait (the implementation of the Method lockinterruptibly ()). Reetrantlock application can illustrate: If A, B2 thread to compete for the lock, a thread gets the lock, b thread wait, but a thread this time there is too much to deal with, is not return, B thread may be able to wait, want to interrupt themselves, no longer wait for this lock, Instead of dealing with other things. This time Reentrantlock provides 2 mechanisms, first, the B thread interrupts itself (or another thread interrupts it), but Reentrantlock does not respond, continue to let the B thread wait, how you interrupt, I am all one ear (synchronized the original language is so) Second, the B thread interrupts itself (or the other thread interrupts it), Reentrantlock handles the interrupt, and no longer waits for the lock to come and completely abandon it.

Java Multithreaded Learning notes--some understanding of multithreading data synchronization from the Java JVM