In-depth analysis of ReentrantLock (fair lock, unfair lock)

In-depth analysis of ReentrantLock (fair lock, unfair lock)

It is similar to a Synchronized mutex and can guarantee thread safety. Based on the powerful concurrency features of AQS and the ability to handle multi-threads, ReentrantLock has more features than Synchronized, such as support for manual locking and unlocking, and support for fair locks.

ReentrantLock uses unfair locks by default, and can also be explicitly specified to use fair locks through the constructor. In ReentrantLock, there are two more classes inherited from Sync:

• NonfairSync (unfair lock)

• FairSync (fair lock)

1.1 Fair lock

A very important attribute sync of reentrantLock, because reentrantlock does not directly inherit the AbstractQueuedSynchronizer class, but inherits the AbstractQueuedSynchronizer class by its attribute sync. The state attribute to judge whether it can be locked is from AbstractQueuedSynchronizer, and the exclusiveOwnerThread attribute is also from AbstractQueuedSynchronizer. exclusiveOwnerThread is used to store the thread currently holding the lock.
Thread 1 comes in to try to get the lock, first to judge whether the attribute state (modified by volatile, the default is 0, modify its value, other threads can immediately sniff and regain its value) is equal to 0, and if it is equal to 0, the lock is obtained , and set the state to 1. Other threads come in and try to get the lock, and also judge whether the value of the state is 0, if it is not 0, enter the waiting queue (two-way list "CLH").
When thread 1 releases the lock, the state becomes 0, and the thread that just came in tries to get the lock, by judging whether hasQueuePredecessors (judging whether there are threads waiting in the queue by judging whether the queue head+1 is equal to the tail) is false to determine whether it can Whether to get the lock, the thread can only get the lock when there are no other threads waiting in the queue, otherwise it has to enter the tail of the queue to wait.

1.2 Unfair lock

After the unfair lock gets state=0, try to lock it directly. Multiple threads try to set the state to 1 through SetState of CAS. When thread 2 is successfully set, assign the current thread to the exclusiveOwnerThread attribute, but it fails Threads enter the queue. When thread 2 tries to acquire the lock again, it first judges whether the exclusiveOwnerThread attribute is equal to thread 2. Since it is the same thread, the state value is +1 (reentrant lock).

1.3 After thread preemption fails

After other threads fail to preempt, they try to enter the queue

private Node addWaiter(Node mode){
    Node node = new Node(Thread.currentThread(), mode); 
   // Try the fast path of enq; backup to full enq on failure
   	Node pred = tail;
      if (pred != null) { 
           node.prev = pred; 
              if (compareAndSetTail(pred, node)) {
                  pred.next = node; return node; 
              } 
      }
    enq(node); 
    return node; 
}

The first cycle will set the head (head) and tall (tail) of the queue to null through CAS, put the newly created node on the head, and the second cycle will have the thread (the thread that entered the waiting queue for the first time) The prev of the node points to the empty node and the next of the empty node points to the node with the thread. At this time, the head of the queue points to the empty node, and the tall points to the node with the thread.

Threads that do not enter the waiting queue for the first time are stored in the node and the prev of the node points to the tall of the queue, and the next of the tall of the queue points to the node. After completion, the tall of the queue points to the newly incoming node.

Threads entering the queue need to be blocked. Before blocking, the next at the head of the queue will grab a lock. If the lock is successfully grabbed, the head node will exit the queue, otherwise it will enter blocking. These blocked threads are woken up in lock.unlock().

Guess you like

Origin blog.csdn.net/ILIKETANGBOHU/article/details/127120007