Go: One of Java concurrent programming: Reentrant built-in lock

Each Java object can be used as a lock that implements synchronization, which is called a built-in lock or a monitor lock. The thread acquires the lock automatically before it enters the synchronization code block, and the lock is automatically released when the synchronization code block exits. The only way to get a built-in lock is to enter a synchronous code block or method protected by this lock.

When a thread requests a lock held by another thread, the thread that makes the request blocks. However, because the built-in lock is reentrant, the request succeeds if a thread tries to acquire a lock that is already held by itself. "Reentrant" means that the granularity of the operation that acquires the lock is "thread", not a call. An implementation of re-entry

The method is to associate a Get count value and an owner thread for each lock. When the count is 0 o'clock, the lock is considered not to be held by any thread, and when the thread requests a lock that is not held, the JVM will note the lock's holder, and the fetch count value to 1, if the same thread acquires the lock again, the count will increment, and the counter will decrement when the thread exits the synchronization code block. When the count value is 0 o'clock, the lock is released.

The re-entry further enhances the encapsulation of the locking behavior, thus simplifying the development of object-oriented concurrency code. The following procedures are analyzed:

[Java]View plain copy

2. Public class Father
4. {
6. public synchronized void DoSomething () {
8. ......
10. }
12. }
16. Public class child extends Father
18. {
20. public synchronized void DoSomething () {
22. ......
24. super.dosomething ();
26. }
28. }

Subclasses override the parent class's synchronization method, and then call the method in the parent class, which creates a deadlock if there are no reentrant locks.

Because the dosomething methods in both Fither and child are synchronized methods, each DoSomething method acquires a lock on the child object instance before it executes. If the built-in lock is not reentrant, the mutex on the child object will not be available when calling super.dosomething because the lock is already held, and the thread will block forever, waiting for a lock that will never be acquired. Re-entry avoids the occurrence of this deadlock condition.

When the same thread calls the Synchronized method/block in the other synchronized method/block or parent class in this class, it does not prevent the thread from executing because the mutex can be reentrant.

Go: One of Java concurrent programming: Reentrant built-in locks