Java Multithreading 4:synchronized Lock mechanism

Dirty Read

A common concept. In multi-threading, it will inevitably occur in multiple threads on the same object's instance variable for concurrent access, if not do the correct synchronization, then the result is "dirty read", that is, the data taken is actually changed.

It's normal to print "a num = 100" and "b num = 200", but now print "b num = 200" and "a num = 200", which is a thread safety issue. We can think about how the thread safety issues are:

1, Mt0 First run, assign Num 100, and then print out "a set over!", start to sleep

2, mt0 in sleep, MT1 run, assign Num 200, and then print "B set over!", and then print "b num = 200"

3, MT1 sleep, because mt0 num and mt1 num is the same num, so MT1 changed num to 200, mt0 no way, for it, NUM can only be 100,mt0 continue to run the code, print out "a num = 200"

Analysis of the cause of the problem, the solution is very simple, to Addnum (String UserName) method and synchronization can be:

The way the results are printed is changed, the order of printing is crossed, and what is this?

Here is an important concept. the lock acquired by the keyword synchronized is an object lock, not a piece of code or method (function) as a lock , which thread first executes the method with the Synchronized keyword, which thread holds the lock of the object to which the method belongs. Other threads can only be in a wait state. But there is a premise: since locks are called object locks, it is bound to be related to objects, so multiple threads must access the same object .

If multiple threads are accessing multiple objects, the Java virtual machine creates multiple locks, as in the example above, creating two ThreadDomain13 objects, resulting in 2 locks. Since two threads hold different locks, it is natural that the code in Addnum (String userName) can be run separately from the "Wait for release lock" behavior.

Synchronized method and lock object

As seen from the result, the first thread invokes the MethodA () method of the entity class, and the second thread can call the MethodB () method of the entity class entirely. But we changed the MethodB () method to synchronous, so we don't list the modified code, and look at the results of the operation:

From this example we draw two important conclusions:

1.A thread holds the lock lock for an object, and a B thread can asynchronously invoke a method of the non-synchronized type in the object.

2,a thread holds the lock lock for object, and a B thread needs to wait for a method to invoke the synchronized type in the object, that is, to synchronize

Synchronized lock re-entry

The keyword synchronized has a lock-in feature. The so-called lock re-entry means that when a thread obtains an object lock, it can again get the lock of the object once it is requested again. See an example:

See that you can directly invoke the print statement in ThreadDomain16, which proves that the object can get its own internal lock again. This mechanism of lock re-entry is also supported in environments where parent-child classes inherit .

Exception Auto Release lock

The last point of knowledge is an exception. When a thread executes a code exception, the locks it holds are automatically freed . The simulation is a long number as a divisor, starting from the Max_value decrement, until reduced to 0, resulting in arithmeticexception. Take a look at the example:

Because the printed result is static, it is not obvious. In l--before a sentence plus thread.sleep (1) The conclusion will be more obvious, after the first sentence, the entire program is stopped, until the Thread-0 throws an exception, Thread-1 can run , which also proves our conclusion.

Java Multithreading 4:synchronized Lock mechanism