Java concurrency lock_ Power node Java college sorting

According to the time when the lock was added to Java, the lock in Java can be divided into "synchronous lock" and "lock in JUC package".

Synchronous lock

That is, synchronize through the synchronized keyword to realize the lock of mutually exclusive access to competing resources. Synchronous locking is already supported in Java version 1.0.

The principle of synchronization lock is that for each object, there is and only one synchronization lock; Different threads can access the synchronization lock together. However, at the same time point, the synchronization lock can and can only be obtained by one thread. In this way, the thread that obtains the synchronization lock can schedule the CPU and execute on the CPU; The thread that does not obtain the synchronization lock must wait until it obtains the synchronization lock. This is the principle of multithreading synchronization through synchronization lock! 　

Locks in the JUC package

Compared with synchronous lock, the lock in JUC package is more powerful. It provides a framework for lock, which allows more flexible use of lock, but its usage is more difficult.

The locks in the JUC package include three abstract classes: lock interface, readwritelock interface, locksupport blocking primitive, condition condition condition, abstractownablesynchronizer / abstractqueuedsynchronizer / abstractqueuedlongsynchronizer, reentrantlock exclusive lock and reentrantreadwritelock read-write lock. Countdownlatch, cyclicbarrier and semaphore are also implemented through AQS; Therefore, I also summarize them into the lock framework for introduction.

First look at the frame diagram of the lock, as shown below.

01. Lock interface

The lock interface in the JUC package supports lock rules with different semantics (reentry, fairness, etc.). The so-called semantic difference means that locks can have "locks with fair mechanism", "locks with unfair mechanism", "reentrant locks" and so on. "Fair mechanism" means that "the mechanism for different threads to obtain locks is fair", while "unfair mechanism" means that "the mechanism for different threads to obtain locks is unfair", and "reentrant lock" means that the same lock can be obtained by one thread multiple times.

02. ReadWriteLock

The readwritelock interface defines some locks that can be shared by readers and exclusive to writers in a similar way to lock. The JUC package has only one class that implements this interface, reentrantreadwritelock, because it applies to most standard usage contexts. But programmers can create their own implementations for non-standard requirements.

03. AbstractOwnableSynchronizer/AbstractQueuedSynchronizer/AbstractQueuedLongSynchronizer

Abstractqueuedsynchronizer is a class called AQS. It is a very useful superclass that can be used to define locks and other synchronizers that depend on queued blocking threads; Reentrantlock, reentrantreadwritelock, countdownlatch, cyclicbarrier and semaphore are all implemented based on AQS classes. The abstractqueuedlongsynchronizer class provides the same functionality, but extends 64 bit support for synchronization status. Both extend the class abstractownablesynchronizer, a simple class that helps record the threads that currently maintain exclusive synchronization.

04. LockSupport

Locksupport provides "create lock" and "basic thread blocking primitives for other synchronization classes".

The function of locksupport is somewhat similar to "thread. Suspend() and thread. Resume() in thread". The functions of park() and unpark() in locksupport are to block threads and unblock threads respectively. However, Park () and unpark () will not encounter the problem of "deadlock caused by thread.suspend and thread.resume".

05. Condition

Condition needs to be used in combination with lock. Its function is to replace the object monitor method. You can sleep / wake up threads through await(), signal(). The condition interface describes condition variables that may be associated with locks. These variables are similar in usage to object Wait access is similar to the implicit monitor, but provides more powerful functionality. In particular, a single lock may be associated with multiple condition objects. To avoid compatibility problems, the name of the condition method is different from that in the corresponding object version.

06. reentrantlock

Reentrantlock is an exclusive lock. The so-called exclusive lock refers to a lock that can only be occupied alone, that is, a lock that can only be obtained by one thread lock at the same point in time. Reentrantlock locks include "fair reentrantlock" and "unfair reentrantlock". "Fair reentrantlock" means that "the mechanism for different threads to obtain locks is fair", while "unfair reentrantlock" means that "the mechanism for different threads to obtain locks is unfair", and reentrantlock is a "reentrant lock".

The UML class diagram of reentrantlock is as follows:

(01) reentrantlock implements the lock interface. (02) reentrantlock has a member variable sync, which is of sync type; Sync is an abstract class, and it inherits from AQS. (03) reentrantlock includes fairsync and nonfairsync, which are subclasses of sync. The sync object in reentrantreadwritelock is one of fairsync and nonfairsync, which also means that reentrantlock is one of "fair lock" or "unfair lock", and reentrantlock is a non fair lock by default.

07. reentrantreadwritelock

Reentrantreadwritelock is the implementation class of the read-write lock interface readwritelock. It includes subclasses readlock and writelock. Reentrantlock is a shared lock and writelock is an exclusive lock.

The UML class diagram of reentrantreadwritelock is as follows:

(01) reentrantreadwritelock implements the readwritelock interface. (02) reentrantreadwritelock contains sync object, readerlock for read lock and writerlock for write lock. Both readlock and writelock implement the lock interface. (03) like "reentrantlock", sync is of sync type; Moreover, sync is also an abstract class inherited from AQS. Sync also includes fair lock fairsync and non fair lock nonfairsync.

08. CountDownLatch

Countdownlatch is a synchronization helper class that allows one or more threads to wait until a set of operations are completed in other threads. The UML class diagram of countdownlatch is as follows:

Countdownlatch contains the sync object, which is of sync type. The sync of countdownlatch is an instance class, which inherits from AQS.

09. CyclicBarrier

Cyclicbarrier is a synchronization helper class that allows a group of threads to wait for each other until they reach a common barrier point. Because this barrier can be reused after releasing the waiting thread, it is called a circular barrier.

The UML class diagram of cyclicbarrier is as follows:

Cyclicbarrier contains "reentrantlock object lock" and "condition object trip", which is implemented through exclusive lock. The difference between cyclicbarrier and countdownlatch is: (01) the function of countdownlatch is to allow 1 or n threads to wait for other threads to complete execution; Cyclicbarrier allows n threads to wait for each other. (02) the counter of countdownlatch cannot be reset; The cyclicbarrier counter can be used after being reset, so it is called a circular barrier.

10. Semaphore

Semaphore is a counting semaphore, and its essence is a "shared lock".

Semaphores maintain a semaphore permission set. Threads can obtain semaphore permission by calling acquire(); When there is a license available in the semaphore, the thread can obtain the license; Otherwise, the thread must wait until a license is available. A thread can release its semaphore license by releasing ().

The UML class diagram of semaphore is as follows:

Like "reentrantlock", semaphore contains sync objects, which are of sync type; Moreover, sync is also an abstract class inherited from AQS. Sync also includes fair semaphore fairsync and unfair semaphore nonfairsync.

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.