ReentrantLock非公平模式下获取和释放锁的源码学习

最新推荐文章于 2024-01-02 22:54:36 发布
原创 最新推荐文章于 2024-01-02 22:54:36 发布 · 417 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#ReentrantLock #多线程 #源码

ReentrantLock类

A reentrant mutual exclusion Lock with the same basic behavior and semantics as the implicit monitor lock accessed using synchronized methods and statements, but with extended capabilities.

ReentrantLock是一个可重入的互斥锁，它具有与使用synchronized的方法和语句访问的隐式监视器锁相同的基本行为和语义，但它具有可扩展的能力。------JDK API

ReentrantLock类有三个静态内部类：

  • Sync类
  • NonfairSync类
  • FairSync类。

其中Sync类继承自AbstractQueuedSynchronizer(抽象队列同步器)，而FairSync和NonfairSync为Sync类的两个实现，分别应用于公平锁和非公平锁的场景。

ReentrantLock类的大部分逻辑，都是由Sync类实现的。

ReentrantLock提供了公平锁机制，构造方法接收一个可选的公平参数。当设置为true时，它是公平锁，这时锁会将访问权授予等待时间最长的线程。否则该锁将无法保证线程获取锁的访问顺序。

公平锁与非公平锁相比，使用非公平锁的程序会有较高的吞吐量，但使用公平锁能有效减少线程饥饿的发生。

AbstractQueuedSynchronizer类

AbstractQueuedSynchronizer即抽象队列同步器，AbstractQueuedSynchronizer类内部维护了一个FIFO的队列，是构建锁或者其他相关同步装置的基础框架。使用队列的好处，可以有效避免惊群效应，防止线程的过度唤醒。

AQS(AbstractQueuedSynchronizer)同步器拥有三个成员变量：队列的头结点head、队列的尾节点tail和状态变量state。

private transient volatile Node head;
private transient volatile Node tail;
private volatile int state;

简单来说，当一个线程访问锁资源时，大致会经历如下步骤：

  1. 当前线程首先判断同步器的state变量的值，如果state为0，则表示锁资源没有被任何线程获取，经过一系列的操作，当前线程获取锁资源。
  2. 如果state>0,则表示当前锁资源已经被某个线程获取，此时当前线程会继续获取同步器exclusiveOwnerThread属性的值，该属性表示当前锁资源被哪个线程占有，如果exclusiveOwnerThread属性的值是当前线程对象，则表示该锁被重入，当前线程成功获取锁资源。
  3. 如果exclusiveOwnerThread属性的值不是当前线程对象，则表示锁资源被其他线程占有，此时线程会将自己封装成一个Node节点，将该节点添加到AQS同步器所维护的队列的队尾，并阻塞当前线程。

示意图如下：

在这里插入图片描述

整体类图关系如下图所示：

在这里插入图片描述

ReentrantLock获取非公平锁的源码学习

例子：
public static void main(String[] args) throws InterruptedException {
    Lock lock = new ReentrantLock();//创建非公平锁
    try {
        lock.lock();//获取锁资源
        TimeUnit.SECONDS.sleep(2);//模拟业务代码执行
    }catch (Exception e){

    }finally {
        lock.unlock();//释放锁资源
    }
}
ReentrantLock类的构造方法

ReentrantLock类有两个构造方法，不传参数则默认使用非公平模式

public ReentrantLock() {
    sync = new NonfairSync();//默认使用非公平模式
}

public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}
lock.lock()方法

获取锁资源的流程从lock.lock()方法开始

public void lock() {
    sync.lock();//调用内部类Sync中的lock方法
}

前面说过ReentrantLock类的大部分逻辑，都是在Sync类及其子类中实现的。所以sync.lock()才是获取锁资源真正的入口。

sync.lock()方法
/**
*	获取锁资源的入口
*/
final void lock() {
    if (compareAndSetState(0, 1))//使用cas算法更新AQS中的同步状态变量(state)
        setExclusiveOwnerThread(Thread.currentThread());//将当前线程设置为持有锁的线程
    else
        acquire(1);
}

lock()方法的大致逻辑为，先使用cas算法尝试将AQS的state属性更新为1，只有在state的值为0时才能更新成功。因为state表示的是当前锁资源被重入的次数，所以state等于0表示当前锁资源未被任何线程持有，如果cas替换成功，则表示当前线程获取到了锁资源，那么只需要将当前线程标记为持有锁资源的线程（将当前线程对象赋值给AQS的exclusiveOwnerThread属性），整个获取锁的流程就结束了。如果cas替换失败，则执行acquire(1);

acquire(int arg)方法
public final void acquire(int arg) {
	if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
		selfInterrupt();
}

acquire(int arg)方法中涉及三个重要的方法

boolean tryAcquire(int arg)

boolean acquireQueued(final Node node, int arg)

Node addWaiter(Node mode)

先分析tryAcquire(int arg)方法

AQS的tryAcquire(int arg)方法

tryAcquire(int acquires)在AQS中的定义如下，该方法直接抛出了一个异常

protected boolean tryAcquire(int arg) {
    throw new UnsupportedOperationException();//模板模式，具体的实现交给子类完成
}
NonFairSync的tryAcquire(int arg)

因为现在分析的是非公平锁的获取，所以非公平模式的实现如下：

protected final boolean tryAcquire(int acquires) {
	return nonfairTryAcquire(acquires);
}

tryAcquire调用nonfairTryAcquire()

final boolean nonfairTryAcquire(int acquires) {
	final Thread current = Thread.currentThread();
	int c = getState();//获取AQS中的同步状态变量的值
	if (c == 0) {//state为0，表示锁没有被任何线程持有
		if (compareAndSetState(0, acquires)) {//使用cas算法将state的值设置为1，即获取锁
			setExclusiveOwnerThread(current);//设置持有锁的线程为当前线程
			return true;
		}
	}else if (current == getExclusiveOwnerThread()) {//如果持有锁的线程是当前线程
		int nextc = c + acquires;
		if (nextc < 0) // 一个线程支持的最大重入次数为 2147483647，超出则会抛出Error
			throw new Error("Maximum lock count exceeded");
		setState(nextc);//设置state值
		return true;
	}
	return false;
}

上面代码是非公平模式下获取锁资源的流程，分为三种情况：

  1. 如果锁资源没有被任何线程所持有，则直接获取锁资源
  2. 如果锁已经被当前线程获取，则对AQS的状态变量加1，表示锁的重入次数加1
  3. 否则将返回false，表示获取锁资源失败

返回到上面的的acquire方法：

public final void acquire(int arg) {
	if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
		selfInterrupt();
}

由上面代码可以看出只有当tryAcquire(arg)返回false（没有获取到锁资源）才会执行后面的代码

acquireQueued(addWaiter(Node.EXCLUSIVE), arg)
addWaiter(Node.EXCLUSIVE)
private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);//将当前线程封装到一个Node节点中
    Node pred = tail;
    //---start---
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) {
            pred.next = node;
            return node;
        }
    }
    //---end---
    enq(node);//enq方法中也有上面注释包围的逻辑
    return node;
}

上面代码的注释括起来的部分可以不看，因为在下面的enq(node)方法中也有同样的逻辑。

enq(final Node node)方法
//参数为封装了当前线程的node对象
private Node enq(final Node node) {
    for (;;) { 
        Node t = tail;
        if (t == null) { //链表为空，此时表示链表需要初始化
            if (compareAndSetHead(new Node()))//创建一个空节点，并将其设置为链表的head
                tail = head;//Q2
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {//使用cas算法将当前节点设置为链表的尾节点
                t.next = node;//Q2
                return t;
            }
        }
    }
}

enq(final Node node)方法的大体逻辑为如果链表为空则初始化链表，头结点为一个空节点，第二次循环时将当前线程的节点添加在队列的末尾。

问题1：既然enq(final Node node)方法中已经包含了上面addWaiter(Node mode)方法中的部分逻辑，为什么相同的逻辑要写两遍？
在通用的逻辑处理之前提前处理某些特殊的逻辑，优点是可以提升性能，缺点是牺牲代码的简洁性。
问题2：enq(final Node node)方法中Q2注释处的代码为什么不用cas算法，这样做是线程安全的吗？
for (;;) { 
    Node t = tail;
    if (t == null) { 
        if (compareAndSetHead(new Node()))//1
            tail = head;
    } else {
        node.prev = t;
        if (compareAndSetTail(t, node)) {
            t.next = node;
            return t;
        }
    }
}

private final boolean compareAndSetHead(Node update) {
    //调用Unsafe类的compareAndSwapObject方法设置头结点
    //compareAndSwapObject是一个native方法，参数列表如下
    //第一个参数：要修改的对象
    //第二个参数：要修改的对象的属性在内存中地址的偏移量
    //第三个参数：预期值
    //第四个参数：要设置的值
    return unsafe.compareAndSwapObject(this, headOffset, null, update);
}

相关代码如上面所示，假设有两个线程同时执行到注释1处的if语句，因为compareAndSetHead方法使用cas算法实现，所以两个线程中只会有一个线程成功设置头结点，而另外一个线程设置头结点时因为实际值和预期值不相等，则会设置失败。所以后面的 tail = head;语句不会有线程安全问题。

acquireQueued(final Node node, int arg)

返回到上面的代码：

public final void acquire(int arg) {
	if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
		selfInterrupt();
}

由上面的代码可知，调用addWaiter方法将当前线程封装成一个Node节点，并将该节点添加到队列的末尾后将会执行acquireQueued(final Node node, int arg)方法，该方法的逻辑如下所示：

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;//线程中断标志
        for (;;) {
            final Node p = node.predecessor();//获取node节点的前驱节点
            if (p == head && tryAcquire(arg)) {//判断node节点的前驱节点是否是头结点且再次尝试获取锁
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            //shouldParkAfterFailedAcquire方法：判断当前线程是否应该被中断
            //parkAndCheckInterrupt方法：中断当前线程
            if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

上面代码的主要逻辑为：

  1. 先获取当前节点前驱节点，判断前驱节点是否是头结点。
  2. 如果前驱节点是头结点，那么会再次尝试获取锁资源。
  3. 如果前驱节点是头结点且再次获取锁资源成功，则将当前节点设置为头结点，返回false。
  4. 如果if p == head && tryAcquire(arg)的结果为false，即前驱节点不是头结点或前驱节点是头结点但是尝试获取锁资源失败，则会执行shouldParkAfterFailedAcquire(Node pred, Node node)方法判断当前线程是否应该被中断。
  5. 如果shouldParkAfterFailedAcquire(Node pred, Node node)方法返回true则执行parkAndCheckInterrupt()方法中断当前线程，并返回true，否则将继续自旋直到满足上述某一条件。
/*
* 	Node.SHARED = new Node(); 状态位，表示当前节点使用共享模式等待
*	Node.EXCLUSIVE = null; 状态位，表示当前节点使用独占模式等待
*	Node.CANCELLED = 1; 状态位，表示当前线程已被取消
*	Node.SIGNAL = -1; 状态位，表示后继线程需要取消阻塞
*	Node.CONDITION = -2; 状态位，表示线程由于阻塞而处于等待状态
*	Node.PROPAGATE = -3; 状态位，表示处于共享模式下，下一次的acquire需要无条件的传播
* 	None of the above    0 
*
*	可以看到代码中会将前驱节点的状态设置为Node.SIGNAL，因为在后面线程释放锁并唤醒其他线程的逻辑中，只有	
*	waitStatus为Node.SIGNAL的节点才能唤醒后继节点封装的线程
*/
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus;//获取前驱节点的等待状态
    if (ws == Node.SIGNAL)
        return true;
    if (ws > 0) {//将状态为“取消”的线程从队列中剔除
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);//使用cas将waitStatus的值设置为Node.SIGNAL
    }
    return false;
}

//中断当前线程
private final boolean parkAndCheckInterrupt() {
    LockSupport.park(this);
    return Thread.interrupted();
}

时序图如下：
在这里插入图片描述

在这里插入图片描述

ReentrantLock释放非公平锁的源码学习

调用ReentrantLock类的unlock()方法
public void unlock() {
    sync.release(1);//调用内部类Sync中的release方法
}
调用Sync的release(int arg)方法
public final boolean release(int arg) {
    if (tryRelease(arg)) {//尝试释放锁资源
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);//唤醒后继节点所封装的线程
        return true;
    }
    return false;
}

//模板方法，具体逻辑由子类实现
protected boolean tryRelease(int arg) {
    throw new UnsupportedOperationException();
}

protected final boolean tryRelease(int releases) {
    int c = getState() - releases;//将状态变量state的值减1
    //如果当前线程不是持有锁资源的线程，则抛出非法锁监视器状态异常
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;//当状态变量state为0时意味着锁被完全释放
        setExclusiveOwnerThread(null);//设置持有锁的线程为空
    }
    setState(c);
    return free;
}

private void unparkSuccessor(Node node) {
    int ws = node.waitStatus;
    if (ws < 0)//如果节点的waitStatus<0，则将其设置为0(初始状态)
        compareAndSetWaitStatus(node, ws, 0);

    Node s = node.next;//获取头节点的后继节点
    //如果后继节点为null或后继节点的状态为canceled，则从尾节点开始遍历，
    if (s == null || s.waitStatus > 0) {
        s = null;
        //找到离头结点最近的非cancelled状态的节点
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    if (s != null)
        //唤醒该线程
        LockSupport.unpark(s.thread);
}
ReentrantLock获取锁、释放锁源码浅析
weixin_34122548的博客
06-16 697
JUC包下的ReentrantLock是基于Aqs模板实现的，它区分公平锁和非公平锁，内部实现了两个同步器，本文关注非公平锁部分。 伪代码 我们先看两个伪代码： 1、获取锁 1 if(获取锁成功) { 2 return 3 } else { 4 加入等待队列 5 for(死循环) { 6 if (获取到锁) { 7 ...
ReentrantLock释放锁源码
weixin_33674976的博客
01-22 164
2019独角兽企业重金招聘Python工程师标准>>> ...
ReentrantLock 锁释放源码分析
weixin_30872337的博客
07-19 99
ReentrantLock 锁释放源码分析： 调用的是unlock 的方法： public void unlock() { sync.release(1); } 接下来分析release() 方法： public final boolean release(int arg) { // arg=1 if (tryRelease(ar...
干货ReentrantLock非公平锁源码分析
singwhatiwanna
09-29 158
hello~各位读者好，我是鸭血粉丝（大家可以称呼我为「阿粉」）。今天，阿粉带着大家来了解一下ReentrantLock锁的非公平锁的实现原理。1.锁java中,加锁的方式1. sy...
ReentrantLock之非公平锁的实现
qq_41911762的博客
10-31 455
Lock接口、ReentrantLock、Sync、FairSync、NonFairSync、AbstractQueuedSynchronizer（AQS）的关系： ReentrantLock实现了Lock接口；Sync是ReentrantLock中的一个内部抽象类、继承了AQS；FairSync和NonfairSync都是ReentrantLock中的内部类，都继承了Sync，并且实现了S...
ReentrantLock非公平锁实现原理解读
JMU_software19的博客
12-17 960
概述 ReentrantLock基于AQS，在并发编程中可以实现公平锁和非公平锁来对共享资源进行同步，同时和synchronized一样，支持锁重入，除此之外，RenentrantLock更加灵活，支持实现更多丰富的功能。说到ReentrantLock根据它的中文名，翻译过来叫做，可重入锁。但是仅仅用可重入一个特性来描述ReentrantLock好像有点以偏概全，其公平锁，非公平锁的实现，以及condition的实现似乎都很重要。所以这也是编程人员命名的一个烦恼。 基于上...
AQS（AbstractQueuedSynchronizer）框架之——ReentrantLock源码分析（公平锁与非公平锁流程图）
sgabon的博客
07-27 453
AQS（AbstractQueuedSynchronizer）框架之——ReentrantLock源码分析 最近在学习AQS框架的ReentrantLock源码，通过debug加锁解锁，观察到lock持有锁时的几种情况，遂通过作图来加深印象。 AQS说明： 重要的属性：head(头)、state(锁状态，0：未加锁 1：加锁)、exclusiveOwnerThread(当前持有的线程)、tail(尾) 其中Node参数的重要属性：prev(前驱结点)、next(后继节点)、Thread(赋予的线程) 加
从ReentrantLock理解AQS的原理及应用总结
热门推荐
张彦峰的博客
05-12 170万+
本文介绍了Java中的AbstractQueuedSynchronizer（AQS），重点讲解了其在实现ReentrantLock等同步器中的应用。文章分析了AQS的基本概念、工作原理及关键数据结构，并探讨了其在多线程竞争中的线程排队与唤醒机制。通过对AQS实现的深入剖析，帮助开发者更好地理解并发编程中的锁机制和自定义同步器的实现。
用synchronized实现的就一定是非公平锁吗？ReentrantLock(true)得到的“公平锁”真的公平吗？
qq_25156781的博客
01-02 1891
如果调用了Object中的wait方法，那么节点会转移到waitSet队列中，只有再次调用notify方法 才能将waitSet队列中的头节点放入entryList或者cxq，notifyAll 全部节点加入到cxq中（EntryList头结点线程叫做 OnDeck Thread，notifyAll不管cxq中是否为空，都会将待唤醒的线程节点都放到cxq中），然后在由线程释放锁之后进行唤醒On Deck线程。而我们平时所用的传参obj，其实不是锁对象，而是被锁的对象，也叫参照对象。也不是绝对的公平的机制。
7、深入理解AQS独占锁之ReentrantLock源码分析(1).pdf
02-28
它可以显式地控制锁的获取和释放，并提供了公平性和非公平性两种获取策略。此外，ReentrantLock还支持尝试获取锁的功能，即在指定时间内尝试获取锁而不阻塞。 #### 3.2 ReentrantLock使用方式 - **创建实例**：通过...
并发编程—ReentrantLock锁的竞争与释放(一)
hansmall的博客
01-09 342
1.ReentrantLock原理介绍 ReentrantLock锁的获取也是基于AQS(AbstractQueuedSynchronizer)来实现的. AQS它是一个同步工具，它有两个功能一个是独占，独占就是说只有一个线程可以获取锁，也就是互斥。另外一个是共享.，共享就是可以有多个线程可以获取锁，像读写锁就是共享的。 在AQS当中维护了一个双向链表，当线程发生竞争时，它会将线程封装成一个N...
可重入锁ReentrantLock详解
Donald_Draper
03-05 312
AtomicInteger解析：[url]http://donald-draper.iteye.com/blog/2359555[/url] 锁持有者管理器AbstractOwnableSynchronizer：[url]http://donald-draper.iteye.com/blog/2360109[/url] AQS线程挂起辅助类LockSupport：[url]http://don...
ReentrantLock源码分析(二)
XiaoBai_DaShen的博客
08-27 381
一、简介       上一篇文章讲到，ReentrantLock方法的实现全部是依靠Sync的方法。而Sync又是继承了AQS，所以需要重点分析AQS。        AQS的设计是采用模板方法模式的。即如果要使用AQS，就需要继承AQS并重写AQS里指定的方法，
深入理解acquire和release原理源码及lock独有特性acquireInterruptibly和tryAcquireNanos
sophia__yu的博客
11-21 1万+
我们在调用Lock的lock上锁时，其实调用的是AQS的模板方法acquire();在调用lock的unlock时其实调用的是release方法。 public void unlock() { sync.release(1); } ...
FairSync与NonFairSync比较
linux_ja的专栏
06-16 2551
通过源码比较二者区别，： static final class FairSync extends Sync { private static final long serialVersionUID = -3000897897090466540L; final void lock() { acquire(1);//直接调用tryAcqui
JavaSE——多线程：Lock体系
LiLiLiLaLa的博客
07-04 482
1.初识Lock与AbstractQueuedSynchronizer(AQS) 1.1.Lock简介 锁是用来控制多个线程访问共享资源的方式，一般来说，一个锁能够防止多个线程同时访问共享资源。在Lock接口出现之前，java程序主要是靠synchronized关键字实现锁功能的，而JDK5之后，并发包中增加了lock接口，它提供了与synchronized一样的锁功能。虽然它失去了像synchr...
深入剖析ReentrantLock公平锁与非公平锁源码实现
舒哥的blog
03-19 2万+
本文以公平与非公平锁的加锁缩成为主线，分析整个加锁过程。准备知识简介ReentrantLock类图： NonfairSync继承关系： Node结点：作为获取锁失败线程的包装类， 组合了Thread引用， 实现为FIFO双向队列。 下图为Node结点的属性描述 锁的创建非公平锁（默认）final ReentrantLock lock = new ReentrantL
读书笔记之《Java并发编程的艺术》—— 二
yaofengdoit的博客
05-30 324
由于内容过多，分一个系列来写，这是第二篇。 三、Java内存模型 1、Java内存模型的基础 线程之间的通信机制有两种：共享内存和消息传递。 在Java里，所有实例域、静态域和数组元素都存储在堆内存中，堆内存在线程之间共享。局部变量、方法定义参数、异常处理参数不会在线程间共享。Java线程之间的通信由Java内存模型(JMM)控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。线程之间的共享变量存储在主内存，每个线程都有一个私有的本地内存(本地内存是JMM的一个抽象概念，并不真实存在)。JMM通过
WebRTC-线程模型（1）
while(1) { smile(); }
11-23 8万+
在介绍WebRTC的线程模型之前，先介绍webrtc线程模型中用到的几个简单、常用的模块或函数。webrtc是一个代码宝库，且它本身跨平台（windows，linux，ios，android），不管是哪个平台上面开发，都可以从中学习到很多有用的东西。一、 设置线程名platform_thread.ccvoid SetCurrentThreadName(const char* name) { #if
公平锁和非公平锁？
最新发布
08-05
嗯，用户这次的问题是关于公平锁和非公平锁的区别及应用场景，正好站内有四个相关引用资料。用户之前还问过偏向锁和自旋锁的问题，看来是在系统学习Java并发锁机制。 从引用内容看，资料[1][2][3][4]都明确区分了两...
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值