Java Multithreading concurrency Lock and atomic operations, do you really understand?

Objective

For Java multithreading, there is no more contact than using synchronized, which is easy to understand, but this synchronized is not the best performance. Today I will briefly introduce several kinds of locks. Maybe I'm talking about a lot of things will not be particularly profound, the best way is to do their own experiments, the various scenarios in the code to experiment, so the hair found a lot of details.

Volatile

As a lightweight lock in Java, when one thread in a multi-threaded operation can ensure that other threads are visible, that is, the "visibility" in the book, and the other is "reordering." The so-called reordering refers to the JVM's optimization of instructions. A lot of people may find that in practical experiments it seems that this is not the case, and the last example I will explain.

Synchronized

This is known as the "heavyweight" thread-safety mechanism in Java, which is not explained here.

Java.util.concurrent.locks.ReentrantLock Java.util.concurrent. is the class library for some concurrent operations in JDK1.5, which includes atomic classes that many classmates like, such as Atomicinteger. It inside the principle is a CAS, here do not do too much elaboration, interested can look at the source code.

Okay, say it. Reentrantlock, this lock is mainly to display the addition of locks and release locks, the benefits are more flexible, more accurate control of the lock, but also to ensure the stability of the system, such as "re-connected." The following code will be used.

Actual scenario

The above describes a few locks, the following with specific code to see the actual use of several locks, as well as various forms of expression. The code is a bit long, so it's best to experiment with it yourself, then look at the results and think about the results.

Output Result:

i>>>>>381890

vi>>>>>353610

ai>>>>>400000

si>>>>>392718

ri>>>>>392658

The result from the above output is really surprising: only the results of atomic operation Atomicinteger ensure the security of multithreading, and other whether it is the use of lightweight volatile or heavyweight synchronized have not achieved the effect we want. This also gives me a big suspicion. Is the problem really so strange?

It is not difficult to see that except Atomicinteger is using its own method and the other is using the Java syntax sugar + + operation. And it reminds me that the + + operation is not an atomic operation, and that it might have caused other threads to make modifications to the other, although the same problem I found in "Think in Java" can be corroborated. One of the problems here is synchronized: Because I have added synchronized operation to SI, but the result of the output is surprising, is there still a problem? This makes me want to compile this piece of code into a byte-code impulse. Well, the following look at the bytecode (here I alone synchronized this section of the operation out, as analysis, the other several even if, otherwise compiled bytecode a bit more)

For the convenience of looking, first put out the source code

Here are the bytecode, in order to save space, some unimportant parts I will not post

From here to see from the Monitorenter into the security zone to the monitorexit out of the security zone did not find that Si is in the middle State, that is where the problem? To put it simply, the bottom line is still (+ +) operation non-atomic operation, but a lot of people doubt, this is not lock it? Nonsense not much to say, in my in-depth analysis of the Java thread Lock mechanism has a more detailed.

Java Multithreading concurrency Lock and atomic operations, do you really understand?