Shulou(Shulou.com)06/01 Report--

Most people do not understand the knowledge points of this article "java low-level combination AQS implementation class kReentrantLock source code analysis", so the editor summarizes the following contents, detailed contents, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "java underlying combination AQS implementation class kReentrantLock source code analysis" article.

1. Class comments

In ReentrantLock, we used to call it reentrant mutex, which means that the same thread can repeatedly lock or release the lock on the same shared resource. Mutex is the meaning of exclusive lock in AQS, which only allows one thread to acquire the lock.

Let's take a look at the important information on the class comments:

The reentrant mutex has the same functional semantics as the synchronized lock, but is more scalable; the constructor accepts the parameters of fairness, and when fairness is ture, the order of obtaining the lock is guaranteed, but the false does not guarantee; the throughput of the fair lock is low, and the fairness of obtaining the lock does not represent the fairness of thread scheduling The tryLock () no-parameter method does not follow fairness and is unfair (both lock and unlock have fairness and unfairness, while tryLock has only fair locks, so talk about it separately).

We would like to add the second point. The fairness and unfairness of ReentrantLock are aimed at obtaining locks. If it is fair, it can guarantee that the threads in the synchronization queue acquire locks in sequence from beginning to end. If it is not fair, it cannot be guaranteed. In the process of releasing locks, we do not have a fair or unfair argument.

2. Class structure

The ReentrantLock class itself does not inherit AQS and implements the Lock interface, as follows:

Public class ReentrantLock implements Lock, java.io.Serializable {}

API Lock defines various methods for locking and releasing locks. There are several APIs as follows:

/ / acquire the lock method, the thread that cannot acquire the lock will block the queue void lock () in the synchronization queue; / / acquire the interruptible lock void lockInterruptibly () throws InterruptedException;// attempt to acquire the lock, if the lock is idle, immediately return true, otherwise return falseboolean tryLock (); / / lock with timeout waiting time, if the timeout time is up, still do not acquire the lock, return falseboolean tryLock (long time, TimeUnit unit) throws InterruptedException / / release the lock void unlock (); / / get a new ConditionCondition newCondition ()

ReentrantLock is responsible for implementing these interfaces. When we use them, we are directly faced with these methods. The underlying implementation of these methods is handed over to the Sync inner class. The definition of the Sync class is as follows:

Abstract static class Sync extends AbstractQueuedSynchronizer {}

Sync inherits AbstractQueuedSynchronizer, so Sync has a lock framework. According to AQS's framework, Sync only needs to implement a few methods reserved by AQS, but Sync only implements some methods, and some are given to subclasses NonfairSync and FairSync to implement. NonfairSync is an unfair lock and FairSync is a fair lock, which is defined as follows:

/ / two subclasses of the synchronizer Sync lock static final class FairSync extends Sync {} static final class NonfairSync extends Sync {}

The overall structure of several classes is as follows:

Sync, NonfairSync, and FairSync in the figure are all implemented in the form of static inner classes, which also meets the implementation standards defined by the AQS framework.

3. Constructor

There are two types of ReentrantLock constructors, the code is as follows:

/ / No-parameter constructor, equivalent to ReentrantLock (false). The default is unfair public ReentrantLock () {sync = new NonfairSync ();} public ReentrantLock (boolean fair) {sync = fair? New FairSync (): new NonfairSync ();}

The default construction of a no-parameter constructor is an unfair lock, which can be selected by a parametric constructor.

It can be seen from the constructor that fair locks are implemented on FairSync and unfair locks on NonfairSync.

4. Sync Synchronizer

Sync represents the synchronizer, and inherits the AQS,UML figure as follows:

As you can see from the UML diagram, the lock method is an abstract method, which is left to two subclasses, FairSync and NonfairSync, to implement. Let's take a look at the remaining important methods.

4.1. nonfairTryAcquire// attempts to obtain the unfair lock final boolean nonfairTryAcquire (int acquires) {final Thread current = Thread.currentThread (); int c = getState () / / the state of the synchronizer is 0, indicating that no one in the synchronizer holds the if (c = = 0) {/ / the current thread holds the lock if (compareAndSetState (0, acquires)) {/ / marks who the thread currently holding the lock is setExclusiveOwnerThread (current); return true }} / / if the current thread already holds a lock, the same thread can lock the same resource repeatedly. The code implements the reentrant lock else if (current = = getExclusiveOwnerThread ()) {/ / the number of locks held by the current thread + acquires int nextc = c + acquires; / / int has the maximum value.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.