Java Lock--framework

Depending on the time the lock is added to Java, the lock in Java can be divided into " sync lock " and "lock in Juc package ".

Sync Lock

That is, through the Synchronized keyword to synchronize, to achieve a mutually exclusive access to competing resources lock. Synchronization locks are already supported in Java version 1.0.

The principle of a synchronous lock is that there is only one synchronization lock for each object, and the synchronization lock can be accessed by different threads together. However, at the same point in time, the synchronization lock can and can only be obtained by one thread. In this way, the thread that acquires the synchronization lock is able to perform CPU scheduling, which executes on the CPU, and no thread that acquires the synchronization lock must wait until the synchronization lock is acquired before it can continue to run. This is the principle of multi-threaded synchronization through synchronous lock!

For more information on "Sync lock", please refer to the content of "Basic Java lock".

Juc the lock in the package

The lock in the JUC package is more powerful than a sync lock, and it provides a framework for locks that allow for more flexibility in using locks, but it is even more difficult to use.

Juc lock in package, including: Lock interface, Readwritelock interface, Locksupport blocking primitives, condition conditions, abstractownablesynchronizer/ Abstractqueuedsynchronizer/abstractqueuedlongsynchronizer three abstract classes, Reentrantlock exclusive locks, Reentrantreadwritelock read and write locks. Since Countdownlatch,cyclicbarrier and semaphore are also implemented through AQS, I also introduce them into the framework of locks.

Look at the lock's frame diagram first, as shown below.

The. Lock interface

The lock interface in the JUC package supports locking rules that differ in semantics (re-entry, fairness, and so on). The so-called semantic differences, refers to the lock is a "fair mechanism of the lock", "non-fair mechanism of the lock", "reentrant lock" and so on. "Fairness mechanism" refers to "the mechanism of acquiring locks by different threads is fair", while "unfair mechanism" means "the mechanism of acquiring locks by different threads is unfair", "reentrant lock" means that the same lock can be acquired multiple times by a thread.

Readwritelock.

The Readwritelock interface defines a lock in a manner similar to lock that some readers can share while the writer is exclusive. JUC package only one class implements the interface, that is, Reentrantreadwritelock, because it applies to most of the standard usage contexts. But programmers can create their own implementations that apply to non-standard requirements.

Abstractownablesynchronizer/abstractqueuedsynchronizer/abstractqueuedlongsynchronizer.
Abstractqueuedsynchronizer is called the AQS class, which is a very useful superclass that can be used to define locks and other synchronizers that rely on queued blocking threads; Reentrantlock, These classes, such as Reentrantreadwritelock,countdownlatch,cyclicbarrier and semaphore, are implemented based on the Aqs class. The Abstractqueuedlongsynchronizer class provides the same functionality but extends support for 64 bits of the synchronization state. Both extend the class Abstractownablesynchronizer, a simple class that helps to record threads that are currently holding exclusive synchronizations.

Locksupport.
Locksupport provides "create locks" and "basic thread blocking primitives for other synchronization Classes".
Locksupport's functionality is somewhat similar to the Thread.Suspend () and Thread.Resume () in Thread, where Park () and Unpark () in Locksupport are blocking threads and unblocking threads, respectively. However, Park () and Unpark () do not encounter the "deadlock that may be caused by thread.suspend and thread.resume" issues.

Condition.
Condition needs to be used in conjunction with lock, which acts as a substitute for the object monitor method, and can hibernate/wake the thread through await (), signal ().
The Condition interface describes the condition variables that may be associated with a lock. These variables are similar in usage to implicit monitors that use object.wait access, but provide more powerful functionality. It should be noted that a single Lock may be associated with multiple Condition objects. To avoid compatibility issues, the name of the Condition method differs from the corresponding Object version.

Reentrantlock.
Reentrantlock is an exclusive lock. The so-called exclusive lock, refers to only be occupied alone, that is, the same point in time can only be acquired by a thread lock. Reentrantlock locks include "fair reentrantlock" and "non-fair reentrantlock". "Fair reentrantlock" means that "the mechanism by which different threads acquire locks is fair", while "unfair reentrantlock" means "the mechanism by which different threads acquire locks is unfair" and reentrantlock are "reentrant locks".
The UML class diagram for Reentrantlock is as follows:

(Reentrantlock) implements the lock interface.
Reentrantlock has a member variable sync,sync is the sync type; sync is an abstract class, and it inherits from Aqs.
There are "fair lock class" Fairsync and "unfair lock class" Nonfairsync in Reentrantlock, all of which are subclasses of sync. The Sync object in Reentrantreadwritelock is one of the Fairsync and Nonfairsync, which means that Reentrantlock is one of the "fair locks" or "unfair locks", Reentrantlock default is a non-fair lock.

. reentrantreadwritelock
Reentrantreadwritelock is the implementation class for the read-write lock interface Readwritelock, which includes subclasses Readlock and Writelock. Reentrantlock is a shared lock, while Writelock is an exclusive lock.
The UML class diagram for Reentrantreadwritelock is as follows:

Reentrantreadwritelock implements the Readwritelock interface.
The Reentrantreadwritelock contains Sync objects, read-lock ReaderLock, and write-lock WriterLock. Both the read lock Readlock and the write lock Writelock implement the lock interface.
(03) Like "Reentrantlock", Sync is the sync type, and sync is an abstract class that inherits from Aqs. Sync also includes "fair lock" Fairsync and "unfair lock" nonfairsync.

Countdownlatch.
Countdownlatch is a synchronous helper class that allows one or more threads to wait until a set of operations that are performed in another thread is completed.
The UML class diagram for Countdownlatch is as follows:

The countdownlatch contains the Sync object, and sync is the sync type. Countdownlatch's sync is the instance class, which inherits from Aqs.

Cyclicbarrier.
Cyclicbarrier is a synchronous helper class that allows a group of threads to wait for each other until a common barrier point (common barrier points) is reached. Because the barrier can be reused after releasing the waiting thread, it is called a cyclic barrier.
The UML class diagram for Cyclicbarrier is as follows:

Cyclicbarrier is the "Reentrantlock object lock" and "condition Object Trip", which is implemented by an exclusive lock.
　　the difference between Cyclicbarrier and Countdownlatch is:
Countdownlatch's role is to allow 1 or n threads to wait for other threads to complete execution, while Cyclicbarrier allows n threads to wait for each other.
Countdownlatch counters cannot be reset, cyclicbarrier counters can be reset and used, so it is called a circular barrier.

Ten. Semaphore
Semaphore is a count semaphore, and its essence is a "shared lock".
The semaphore maintains a semaphore license set. A thread can obtain a semaphore's license by calling acquire (), and the thread can obtain the license when there is a license available in the semaphore, otherwise the thread must wait until a license is available. The thread can release () The semaphore license it holds.
The UML class diagram for semaphore is as follows:

Like "Reentrantlock", Semaphore contains the Sync object, Sync is the sync type, and sync is an abstract class that inherits from Aqs. Sync also includes "fair semaphore" Fairsync and "non-fair semaphore" Nonfairsync.

Java Lock--framework