Synchronized re-entry of the

See an example of concurrent programming today

public class Widget {
Public synchronized void DoSomething () {
...
}
}

public class Loggingwidget extends Widget {
Public synchronized void DoSomething () {
System.out.println (toString () + ": Calling dosomething");
Super.dosomething ();
}
}

It was supposed to be that there would be a deadlock. But after doing it, I found there was no deadlock. And then found a reasonable explanation, actually the object lock is the same, that is, the child class object lock, and the object lock is reentrant, ensure that no deadlock occurs.

The following content reproduces the great God "mat learning process" of the blog http://blog.csdn.net/aigoogle/article/details/29893667?utm_source=tuicool&utm_medium= Referral

----------------------------------------------------------------------

There is only one object lock here, which is the lock of the child object. When the child.dosomething is executed, the thread obtains a lock on the child object and requests the child object's lock again when executing doanotherthing within the DoSomething method, because synchronized is a re-entry lock, so the lock can be obtained and continue in Doanoth Erthing the DoSomething method of the parent class is requested the third time the child object's lock, the same can be obtained, if it is not a re-entry lock, then this two times after the request lock will be blocked, resulting in a deadlock.

So inside Java, the same thread calls the other synchronized methods/blocks in its own class or calls the Synchronized method/block of the parent class without impeding the execution of the thread, meaning that the same object lock is reentrant on the same threads, and the same one can get the same lock multiple times , which can be re-entered multiple times. Because Java threads are based on "per-thread (per-thread)" rather than "per-call (per-invocation)" (the Java thread obtains object locks in a per-thread-granularity, The per-invocation mutex obtains the object lock operation is in each call as the granularity)

Let's take a look at how the entry lock implements Reentrant, which is implemented by associating a thread holder and a counter for each lock, indicating that the lock is not held by any thread when the counter is 0, and that any thread may acquire the lock and invoke the appropriate method; When a thread request succeeds, the JVM will note the lock's holding threads , and the counter is set to 1, when another thread requests the lock, it must wait, and the thread holding the lock, if requested again, can get the lock again, the counter will increment, and when the thread exits the synchronization code block, the counter decrements, and if the counter is 0, the lock is freed.

Synchronized of re-entry