ReentrantLock源码解析

最新推荐文章于 2024-12-01 14:33:47 发布
最新推荐文章于 2024-12-01 14:33:47 发布
阅读量636 收藏
点赞数 1
分类专栏： jdk锁 文章标签： 可重入锁 jdk 源码
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/luanmousheng/article/details/76369433
版权
ReentrantLock作为JDK的显式锁，提供比synchronized更精细的控制。它是可重入和独占锁，内部通过AbstractQueuedSynchronizer（AQS）实现。ReentrantLock分为公平锁和非公平锁，非公平锁在lock方法中直接尝试获取锁，失败则进入等待队列。公平锁在获取锁前会检查是否有前置节点，确保FIFO特性。释放锁时，会唤醒等待队列中的线程。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

ReentrantLock

ReentrantLock是JDK内置的显示锁，相对于隐式锁synchronized，ReentrantLock提供了比synchronized更精细化的锁控制。通过情况下，我们会这样使用显示锁……

lock.lock();
try {
  //do something
} finally {
   lock.unlock(); 
}

ReentrantLock是可重入锁，意思是当线程A得到了锁后，还可以继续拿到该锁。

ReentrantLock是独占锁，同时只能有一个线程获取该锁。

ReentrantLock和AbstractQueuedSynchronizer的关系

ReentrantLock其实是通过内部类代理实现了锁的功能，内部类继承自AbstractQueuedSynchronizer，后面会简写为AQS，锁的核心实现都来自于AQS。AQS中的tryAcquire、tryRelease、tryAcquireShared、tryReleaseShared都抛出异常，子类如果需要，实现这几个方法即可。

先来简单看下ReentrantLock的声明：

public class ReentrantLock implements Lock, java.io.Serializable {
    //同步器的实现，ReentrantLock都是通过sync代理AQS的
    private final Sync sync;

    //字段……
    //方法……

    //Sync继承了AQS
    abstract static class Sync extends AbstractQueuedSynchronizer {
        //
    }
    //非公平锁
    static final class NonfairSync extends Sync {
    }
    //公平锁
    static final class FairSync extends Sync {
    }
}

ReentrantLock实现了Lock接口，锁的功能是通过内部静态类Sync、NonfairSync、FairSync实现的。

公平锁和非公平锁

公平锁和非公平锁的区别在于获取锁操作过程的差异，后面讲到代码时还会详细介绍，这也是锁的重点，这里简单说明下。

公平锁：检查当前线程的前置结点是否是头结点，如果不是则会继续排队等待，否则获取锁。这种获取锁的方式可以保证队列的FIFO特性，先排队的线程先获取锁，公平地获取锁。但是这种方式效率不高，假如头结点的线程释放了锁，还要去唤醒后一个线程去获取锁，线程上下文切换，成本较高。下图是公平锁的获取示意图：

这里写图片描述

图1：公平锁的获取

非公平锁：获取锁的线程首先去尝试获取锁，如果没有获取成功则会去等待队列排队等待。这种方式首先去尝试获取锁。假如头结点的线程释放了锁，若此时另一个线程恰好去获取非公平锁，那么该线程可以竞争到该锁，免去了释放锁的线程去唤醒后续线程从而引起线程上下文切换。下图是非公平锁的获取示意图：

这里写图片描述

图2：非公平锁的获取

看下ReentrantLock的构造函数：

    //默认构造函数创建非公平锁
    public ReentrantLock() {
        sync = new NonfairSync();
    }
    //通过参数指定创建公平锁还是非公平锁
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

ReentrantLock默认创建的是非公平锁，这是因为非公平锁在实际使用中效率更高。另外还可以通过ReentrantLock提供的带参数的构造函数指定创建公平锁还是非公平锁。

非公平锁的lock方法

前面说到，我们一般会通过调用ReentantLock的lock方法去获取锁，先看下lock的源码：

    public void lock() {
        sync.lock();
    }

lock方法的源码非常简单，锁的功能通过sync代理了。当我们执行如下代码时，将会创建一个非公平锁：

//创建一个非公平锁
Lock lock = new ReentrantLock();

非公平锁是通过内部类NoneFairSync实现的，ReentrantLock有3个静态内部类，分别是Sync、FairSync和NonfairSync。下图是ReentrantLock的简单类图：

这里写图片描述

图3：ReentrantLock简单类图

该图是ReentrantLock的简单类图框架，ReentrantLock的内部类Sync继承自AQS，FairSync和NonfairSync分别继承自Sync，实现了公平锁和非公平锁。

ReentrantLock的lock方法其实是调用Sync的lock方法，而Sync的lock方法是个抽象方法：

abstract void lock();

因此子类需要去实现该抽象方法，非公平锁NonfairSync的实现如下：

    //非公平锁继承了Sync
    static final class NonfairSync extends Sync {
        private static final long serialVersionUID = 7316153563782823691L;

        final void lock() {
            //锁的状态是0代表当前锁是空闲的
            //比较锁的状态是否是0，原子的设置为1，若设置成功，设置独占线程为当前线程
            //此处体现了非公平锁的特点，先尝试获取锁，获取失败再去队列排队获取锁
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                //队列排队获取锁
                acquire(1);
        }
        //稍后会讲解该代码
        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }

    }

可以看到非公平锁的lock实现思路，首先直接去获取锁，若获取锁成功，将当前锁的占有者设置为当前线程。否则调用acquire方法获取锁。

这里先说明下comareAndSetState方法，类似这种CAS方法在JDK的锁框架中大量使用，JDK的锁正是通过CAS原子操作得以实现。

    //该方法是AQS的方法，通过Unsafe类原子的设置字段state为update值，当且仅当state==expect的时候，将       //state设置为update，否则不设置
    protected final boolean compareAndSetState(int expect, int update) {
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
    }

JDK的锁框架大量使用了sun.misc.Unsafe类的compareAndSwapXXX方法，该方法是一个native方法，并且是一个原子操作，不可中断，通过该方法保证了锁操作的正确性。

CAS 操作包含四个参数： 当前对象(this)、内存偏移量（stateOffset）、预期值（expect）和新值(update)。如果内存偏移处存储的值与预期值相同，那么处理器会自动将该位置值expect更新为新值update，否则，处理器不做任何操作。不论是否更新为新值，它都会返回该位置之前的值。

直观的理解，CAS认为位置M处的值应该是V，如果执行过程中的确是这样，将位置M处的值更新为U，否则CAS什么也不做。不管什么情况下，CAS都会返回原先位置M存储的值。

回到lock方法，当if语句中CAS操作成功后，设置当前线程为该锁的独占线程。若获取失败，调用AQS的acquire方法。可以看出，这种获取锁的方式是非公平的，线程不会首先去排队获取锁，而是直接去获取锁，获取不到才会去排队等待获取锁。后面讲到公平锁还会再做比较。

AQS的acquire方法源码如下：

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

这段AQS的代码很重要，需要好好理解。

首先会调用tryAcquire方法，查看该方法，惊奇的发现该方法抛出了异常：

    protected boolean tryAcquire(int arg) {
        throw new UnsupportedOperationException();
    }

说明AQS并没有实现该方法，由子类去实现。看下NonfairSync的tryAcquire实现：

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

tryAcquire调用了父类Sync的nonfairTryAcquire方法，看下该方法的实现：

    //获取非公平锁
    final boolean nonfairTryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
          //如果state=0，说明没有任何线程获取锁，通过CAS去获取
          if (compareAndSetState(0, acquires)) {
            //设置成功后设置锁的拥有者为当前线程
            setExclusiveOwnerThread(current);
            return true;
          }
        }
        //到这里，说明锁已经被某个线程获取，判断是否当前线程获取的，因为ReentrantLock是可重入锁，同一个       //线程可以多次获取锁
        else if (current == getExclusiveOwnerThread()) {
          //将state加上acquires，这里比较好理解
          int nextc = c + acquires;
          if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
          setState(nextc);
          return true;
        }
        //获取锁失败返回false
        return false;
    }

nonfairTryAcquire的代码还是比较好理解的，还是直接看上面注释吧。。

到这里非公平锁的tryAcquire讲完了，让我们回到AQS的方法acquire，免得走得太远，找不到回去的路：

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

如果tryAcquire返回成功，表示当前线程获取锁成功，否则:

  1. 调用addWaiter方法，创建一个Node节点，该节点维护了当前线程的引用，将该节点加入AQS的等待队列中。
  2. 调用acquireQueued排队获取锁。

先介绍下Node，AQS将竞争锁的线程维护在一个双向链表中，这个链表就是锁的等待队列，链表的节点就是Node节点。参考图1，链表头维护的就是已经获取锁的线程A，后面的结点B、C和D是在等待队列中等待获取锁的线程。Node类是AQS的内部静态类，看下Node的源码：

    static final class Node {
        //表示该节点是共享节点，线程需要获取的是共享锁
        static final Node SHARED = new Node();
        //线程需要获取的是独占锁
        static final Node EXCLUSIVE = null;

        //下面几个int值是当前节点的状态选项
       //当前节点的线程因为某些原因（超时、中断等）等不及获取锁，已经取消
        //在这个状态下的结点状态不会再改变，线程也不会被阻塞
        static final int CANCELLED =  1;
        //如果当前结点的状态是-1，当本节点维护的线程释放锁后需要去唤醒后续的线程去获取锁
        static final int SIGNAL    = -1;
        //表示本节点维护的线程处于条件队列中
        //条件队列和等待队列不一样，同一个锁可以对应多个条件队列，当然也可以没有条件队列，
        //一般是通过lock的newCondition方法获取条件队列的，条件队列中的线程被唤醒后会被转移到
        //等待队列中
        static final int CONDITION = -2;
        //当节点的状态为-3时，该节点获取共享锁后需要通知后续的共享节点获取该共享锁
        //ReentrantLock是独占锁，以后介绍读锁时会用到该选项
        static final int PROPAGATE = -3;

        //当前结点的等待状态，只可能为0、1、-1、-2、-3这5种状态
        volatile int waitStatus;

        //前置结点        
        volatile Node prev;
        //后置结点
        volatile Node next;

        //结点维护的等待获取锁的线程
        volatile Thread thread;

        //当前结点线程获取锁是独占模式还是共享模式
        Node nextWaiter;

        //当前结点线程是否要获取共享锁
        final boolean isShared() {
            return nextWaiter == SHARED;
        }

        //返回前置结点
        final Node predecessor() throws NullPointerException {
            Node p = prev;
            if (p == null)
                throw new NullPointerException();
            else
                return p;
        }

        Node() { 
        }
        //mode参数指示了该节点是共享模式还是独占模式
        Node(Thread thread, Node mode) { 
            this.nextWaiter = mode;
            this.thread = thread;
        }

        Node(Thread thread, int waitStatus) { 
            this.waitStatus = waitStatus;
            this.thread = thread;
        }
    }

addWaiter方法创建独占模式的节点，并将该节点入队，看下AQS的addwaiter方法源码：

    private Node addWaiter(Node mode) {
        //传入当前线程、节点模式，创建节点
        Node node = new Node(Thread.currentThread(), mode);
        //快速入队，如果入队失败，调用enq方法自旋入队
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
            //如果当前线程CAS设置尾结点失败，说明有其他线程已经修改了尾结点
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        //自旋入队
        enq(node);
        //返回入队的结点
        return node;
    }

addWaiter方法的实现思路很简单，首先通过CAS原子地设置尾结点，如果设置失败说明有其他线程已经修改了尾结点，调用enq方法自旋入队。自旋其实就是在for循环中不断的通过CAS尝试设置尾结点，如果设置成功说明入队成功，否则继续for循环。enq是AQS的方法，看下enq的源码：

    private Node enq(final Node node) {
        //for循环内通过CAS设置尾结点，设置成功说明入队成功，否则设置失败，继续下一个for循环
        for (;;) {
            Node t = tail;
            if (t == null) { 
                //尾结点为空，初始化头结点，并将尾结点也指向头结点
                if (compareAndSetHead(new Node()))
                    tail = head;
            } else {
                node.prev = t;
                //原子的设置尾结点，设置成功说明入队成功，否则失败
                if (compareAndSetTail(t, node)) {
                    t.next = node;
                    return t;
                }
            }
        }
    }

注意，enq中的comareAndSetHead方法是通过比较当前头结点是否为null，如果为null才会去设置头结点，否则说明其他线程已经设置了头结点，该线程不再去设置。

至此addWaiter方法结束，再看下acquire方法

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

addWaiter方法将结点入队后，继续调用acquireQueued方法去等待队列排队获取锁，看下acquireQueued方法的源码：

    final boolean acquireQueued(final Node node, int arg) {
        //failed表示是否获取锁失败
        boolean failed = true;
        try {
            //等待获取锁过程中线程是否被中断过
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor();
                //前置结点是头结点，尝试获取
                if (p == head && tryAcquire(arg)) {
                    //获取成功后设置头结点为当前结点
                    setHead(node);
                    //快速的被垃圾收集器收集
                    p.next = null; 
                    failed = false;
                    //返回是否被中断过
                    return interrupted;
                }
                //获取锁失败后是否需要挂起当前线程
                //如果需要挂起当前线程，则将当前线程挂起，返回线程在挂起过程中是否被中断过
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    //线程被唤醒后，继续for循环
                    interrupted = true;
            }
        } finally {
            if (failed)
                //获取锁失败，取消当前结点
                cancelAcquire(node);
        }
    }

先说下acquireQueued的思路：

acquireQueued字面意思是在等待队列中获取锁，它确实也是做的这件事。首先它会尝试去获取锁，只有前置节点是头结点的情况下，并且尝试获取锁成功，才会真正获取锁。如果尝试获取锁失败，接下来它需要判断是否要将自己挂起，当前线程在挂起自己之前需要去队列中找到一个小伙伴，告诉该小伙伴当它释放锁之后需要通知自己去获取锁，这样当前线程才能安心的挂起自己了。

当前线程找到通知自己的小伙伴后，设置小伙伴节点的waitStatus为SIGNAL，这样当小伙伴节点释放锁后就知道自己要去通知后续节点线程了。该节点被唤醒后需要继续for循环获取锁。

看下AQS的shouldParkAfterFailedAcquire方法的源码：

    private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        int ws = pred.waitStatus;
        if (ws == Node.SIGNAL)
            //前置节点的状态已经是SIGNAL，当该节点的线程释放锁后自然会去唤醒后续线程，
            //因此可以放心的挂起
            //注意：只有前置节点的状态是SIGNAL，该方法才会返回true，其他情况下该方法都会返回false
            return true;
        if (ws > 0) {
            //节点的waitStatus状态大于0的只有CANCELLED

            //前置节点已经取消了，跳过所有取消的节点，直到找到未取消的节点
            //并将断开的链连接上
            do {
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
            pred.next = node;
        } else {
            //设置前置节点的状态为SIGNAL
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        //到这里说明当前线程不需要挂起，因为前置节点并不是SIGNAL状态
        return false;
    }

shouldParkAfterFailedAcquire返回值表示了当前线程是否需要挂起，只有在当前节点的前置结点状态为SIGNAL时，该方法才会返回true，当前线程可以放心地挂起，否则返回false，当前线程不能挂起。

当前置节点的状态不为SIGNAL时，该方法不是简单的返回false，而是做了一些其他工作，这些工作都是为下一次acquireQueued方法的for循环做准备的。比如本次发现前置节点不是SIGNAL时，若前置节点状态为取消状态，该方法会移除等待队列中排在当前节点前面那些所有已经取消的节点，若前置节点状态不为取消状态，该方法尝试将前置节点的状态设置成SIGNAL。这样下次for循环时，当前节点的前置状态可能就为SIGNAL的，保证能够找到最终唤醒该线程的节点。

再回顾下acquireQueued的该代码片断：

if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt())
     interrupted = true;

shouldParkAfterFailedAcquire返回true后，说明线程需要挂起，调用parkAndCheckInterrupt，该方法很简单，通过LockSupport的park方法挂起当前线程，当线程被唤醒时，返回线程是否中断过，看下AQS中的该方法：

    //挂起当前线程并返回该线程挂起期间是否中断过
    private final boolean parkAndCheckInterrupt() {
        LockSupport.park(this);
        //线程唤醒后返回是否中断过
        return Thread.interrupted();
    }

JDK锁挂起线程都是通过LockSupport来实现的，以后再详细介绍LockSupport，这里暂且不表。

继续回到acquireQueued方法，注意到方法中finally块：

    finally {
            if (failed)
                //获取锁失败，取消当前结点
                cancelAcquire(node);
        }

如果获取锁失败，将当前结点取消，状态设置为CANCELLED。

到些，acquireQueued方法讲解完了，回到acquire方法，当acquireQueud返回true时，说明线程在挂起过程中被中断过，调用selfInterrupte()方法中断自己，设置线程的中断标志位。

到此为止，非公平锁的lock方法讲解完毕。调用层次有点深，做下总结：

  1. 非公平锁获取锁是通过ReentrantLock的NonfairSync类实现的。
  2. 非公平锁首先去尝试获取锁，获取不到才会去等待队列中排队获取锁。
  3. 非公平锁尝试获取锁失败后，将该线程包装成一个Node节点，模式为独占模式，加入等待队列末尾。
  4. 加入等待队列后，需要在等待队列前面找到一个节点，该节点释放锁后能够通知到刚才加入等待队列的节点，这样新加入的节点才能安心的挂起。

公平锁的lock方法

公平锁的lock方法和非公平锁的lock方法是有区别的，先看下ReentrantLock的FairSync实现:

    //公平锁
    static final class FairSync extends Sync {
        private static final long serialVersionUID = -3000897897090466540L;

        //公平锁的lock方法直接调用了AQS的acquire方法，这和非公平锁的实现区别很明显
        //非公平锁先尝试去获取锁，获取失败才会去调用acquire方法
        final void lock() {
            acquire(1);
        }

        //稍后讲解公平锁的tryAcquire方法
        protected final boolean tryAcquire(int acquires) {
            //……
        }
    }

将非公平锁和公平锁的lock代码拿出来比较下：

    //非公平锁lock方法
    final void lock() {
        if (compareAndSetState(0, 1))
          setExclusiveOwnerThread(Thread.currentThread());
        else
          acquire(1);
    }

    //公平锁lock方法
    final void lock() {
        acquire(1);
    }

对比下看出来两种锁获取方式的区别。非公平锁首先尝试去获取锁，获取失败才会去调用acquire方法。

两种lock方法都调用了AQS的acquire方法：

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

这段代码之前已经解释过，这里需要注意的是AQS的tryAcquire方法是抛出异常的，需要由子类去实现。非公平锁调用的tryAcquire是由NonfairSync实现的，同样，公平锁的tryAcquire是由FairSync实现的。

先比较下非公平锁和公平锁tryAcquire的实现：

//非公平锁的tryAcquire实现
protected final boolean tryAcquire(int acquires) {
    return nonfairTryAcquire(acquires);
}
//该方法是Sync类的方法
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
      //非公平锁会直接尝试获取锁
      if (compareAndSetState(0, acquires)) {
        setExclusiveOwnerThread(current);
        return true;
      }
    }
    //……
}
//公平锁的tryAcquire实现
protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
      //公平锁首先判断是否有其他前置线程在等待该锁，若有则不会去获取锁
      if (!hasQueuedPredecessors() &&
          compareAndSetState(0, acquires)) {
        setExclusiveOwnerThread(current);
        return true;
      }
    }
  //……
}

这两个tryAcquire方法不同之处在于公平锁在尝试获取锁之前会通过hasQueuedPredecessors方法判断是否有前置结点在等待获取锁。

锁的释放-release方法

非公平锁和公平锁的释放操作都是相同的：

public void unlock() {
    sync.release(1);
}

释放锁都是调用AQS的release方法，看下AQS的release方法：

//返回锁是否空闲
public final boolean release(int arg) {
    //tryRelease在AQS抛出异常，需要由子类实现
    //但是tryRelease的语义在AQS已经定义了，该方法返回锁是否是空闲的
    if (tryRelease(arg)) {
      //释放锁成功，唤醒后续线程
      Node h = head;
      if (h != null && h.waitStatus != 0)
        //唤醒后续线程
        unparkSuccessor(h);
      return true;
    }
    return false;
}

其中的tryRelease由子类实现，具体的，tryRelease是由静态内部类Sync实现的。看下Sync的tryRelease方法的实现：

protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    //如果获取锁的线程不是当前线程，抛出非法监视器异常
    //只有获取锁的线程才有权释放锁
    if (Thread.currentThread() != getExclusiveOwnerThread())
      throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
      //c=0，说明锁已经完全释放了
      free = true;
      //设置锁的拥有者为null
      setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}

这段代码比较容易理解，直接看注释吧。

回到AQS的release方法，释放锁成功后，需要唤醒后续线程，AQS的unparkSuccessor方法用来唤醒后续线程：

//唤醒node的后续节点
private void unparkSuccessor(Node node) {
    int ws = node.waitStatus;
    if (ws < 0)
      //ws > 0的状态只有一个取消状态
      //状态是非取消状态时，清除状态，不关心是否清除成功
      compareAndSetWaitStatus(node, ws, 0);
    Node s = node.next;
    if (s == null || s.waitStatus > 0) {
      //后一个节点为空或者是取消状态
      s = null;
      //找到后续第一个非取消状态的结点
      for (Node t = tail; t != null && t != node; t = t.prev)
        if (t.waitStatus <= 0)
          s = t;
    }
    //找到后续第一个非取消状态的结点后，唤醒它
    if (s != null)
      LockSupport.unpark(s.thread);
}

等待队列和条件队列

前面我们讲到AQS其实是维护了一个队列，队列的节点是AQS的内部静态类Node。这个双向链表维护了当前等待获取锁的线程，这个队列叫做等待队列。

其实AQS还可以维护另一种队列，这个队列叫做条件队列。当我们调用锁的newCondition时，其实就是创建了一个条件队列，多次调用newCondition，可以创建多个条件队列。

条件队列中的节点如果条件满足，将会被移到等待队列，等待获取锁。

锁的条件队列以后再详细说明，这里就先不说了。

参考：

  1. JDK 1.7.0_79源码
Java 使用ReentrantLock实现同步
抛弃幻想，准备斗争
03-23 1185
Java5中Lock对象实现同步的效果，而且使用上更方便。 1.ReentrantLock类的使用。 2.ReentrantReadWriteLock类的使用。 ReentrantLock能达到synchronized的效果，且扩展功能也更加强大。 例如：嗅探锁定，多路分支通知等。 使用ReentrantLock实现同步： package org.test.t8.t_1; import java...
ReentrantLock-源码解析
编程小白养成手记
09-20 155
公平锁与非公平锁的实现，获取锁与释放锁，ReentrantLock与AQS的关系
ReentrantLock源码
chinaherolts2008的博客
07-30 170
JUC 指java.util.concurrent包下,一系列关于并发的类,JUC就是包名的首字母 CAS 比较并交换,可以看另一篇文章 AQS 指主要利用CAS来实现的轻量级多线程同步机制,并且不会在CPU上出现上下文切换和调度的情况 自定义锁 如何在自己实现一个锁? 可以定义一个属性来判断当前是否有其线程在运行,如果正在运行那么其他线程需要等待 如何实现? 例如有两个线程T1和T2,都执行同一段代码 自定义两个方法 public void lock();..
以RetreentLock为例解析AQS源码
zhou_jianwei的博客
06-13 160
trylock只有非公平锁的实现，走的是nonfairTryAcquire，等价于RetreentLock非公平锁的lock()。Retreent的lockInterruptibly无论是公平锁还是非公平锁都是调用的AQS的lockInterruptibly。RetreentLock的释放锁无论是公平锁还是非公平锁都是unlock()方法，且只有一个unLock释放锁的方法。tryRelease在AQS类中是一个抽象实现，抛出异常，具体的实现在RetreentLock中。
Reentantlock源码解读
w7sss的博客
05-31 214
Reentantlock源码解读 目录 Reentantlock源码解读 前言 源码解读 前言 ReentrantLock是一种基于AQS框架的应用实现，是JDK中的一种线程并发访问的同步手段，它的功能类似于synchronized是一种互斥锁，可以保证线程安全。而且它具有比synchronized更多的特性，比如它支持手动加锁与解锁，支持加锁的公平性。至于AQS，不用多说它的核心地位，它是整个java并发包JUC的基石。AQS定义了一套多线程访问共享资源的同步器框架。 源码解读 话不多说.
ReentrantLock源码解析（二）
12-21
《ReentrantLock源码解析（二）》 在Java并发编程中，ReentrantLock是一个重要的同步工具类，它提供了一种比synchronized更细粒度的锁控制机制。本文主要探讨ReentrantLock的内部实现，特别是其数据结构和关键方法...
第六章 ReentrantLock源码解析2--释放锁unlock()1
08-04
ReentrantLock源码解析之释放锁unlock() ReentrantLock是一个可重入锁，它提供了一个unlock()方法来释放锁。在本章中，我们将深入探讨unlock()方法的源码，了解其释放锁的步骤和机制。 unlock()方法的主要作用是...
并发编程笔记一-ReentrantLock源码深度解析
最新发布
qq_41191331的博客
12-01 1062
通过画图深度的解析ReentrantLock的加锁和释放锁的流程，并对其源码进行结构化的拆解和分析，帮助小伙伴们更快更深层次的理解什么是ReentrantLock。
java锁原理图_轻松学习java可重入锁(ReentrantLock)的实现原理（转 图解）
weixin_39628180的博客
02-13 248
前言相信学过java的人都知道 synchronized 这个关键词，也知道它用于控制多线程对并发资源的安全访问，兴许，你还用过Lock相关的功能，但你可能从来没有想过java中的锁底层的机制是怎么实现的。如果真是这样，而且你有兴趣了解，今天我将带领你轻松的学习下java中非常重要，也非常基础的可重入锁-ReentrantLock的实现机制。听故事把知识掌握了在一个村子里面，有一口井水，水质非常的...
java并发之ReentLock可重入锁(公平锁) 加锁过程
badly的博客
04-16 1128
当线程1进行了加锁，而线程2加入了等待队列，此时如果线程1全部完成了自己的业务逻辑，接下来要释放锁，那么，线程1在释放锁的时候，会唤醒等待队列里面的线程，然后等待队列中的线程2，再次尝试获取锁，一些列的操作逻辑，获取锁成功，修改state=1, 设置加锁线程=线程2等等，依次执行下去 ...
retreenlock 原理 java_深入浅出ReentrantLock
weixin_39911475的博客
02-27 1440
简书 占小狼转载请注明原创出处，谢谢！前言java5之后，并发包中新增了Lock接口(以及相关实现类)用来实现锁的功能，它提供了与synchronized关键字类似的同步功能。既然有了synchronized这种内置的锁功能，为何要新增Lock接口？先来想象一个场景：手把手的进行锁获取和释放，先获得锁A，然后再获取锁B，当获取锁B后释放锁A同时获取锁C，当锁C获取后，再释放锁B同时获取锁D，以此类...
ReetrantLock（选择性通知与公平锁） 侃一侃西游记之--太上老君炼丹的故事
SIX___SIX的博客
02-21 532
目录 一.写在开头 二.太上老君炼丹的故事 三.ReetrantLock选择性通知与公平锁，及部分特性与synchronized的比较 四.代码 一.写在开头 通过一个西游记里头经典的桥段，太上老君炼丹的故事，初步介绍ReetrantLock的选择性通知，ReetrantLock公平锁/非公平锁。希望能够帮助到点进来的你。配合跑代码看结果效果更佳。 二.太上老君炼丹的故事 书接上回...
多线程基础-ReetrantLock
future_xiaowu的博客
07-29 661
参考： https://csp1999.blog.youkuaiyun.com/article/details/116331409 https://blog.youkuaiyun.com/javazejian/article/details/75043422 你知道怎么实现多线程同步问题吗？join不算，还知道吗 - 知乎 (zhihu.com) 学习多线程一段时间后，视野中出现了各式各样的“锁”，起初是眼花缭乱的，但是仔细整理一下发现还是有规律可循的。 现在我理解的大致基础向并发编程学习思路就是 1 多线程基础，包括
浅析ReentrantLock重入锁
wh柒八九的博客
04-08 239
ReentrantLock重入锁，是实现Lock接口的一个类，也是在实际编程中使用频率很高的一个锁，支持重入性，表示能够对共享资源能够重复加锁，即当前线程获取该锁再次获取不会被阻塞。在java关键字synchronized隐式支持重入性，synchronized通过获取自增，释放自减的方式实现重入。与此同时，ReentrantLock还支持公平锁和非公平锁两种方式。 文章目录ReentrantLockReenTrantLock和synchronized的区别 ReentrantLock ReenTr.
ReentrenLock的用法
DO_IT_TODAY的博客
09-21 1846
前言这篇文章，主要是说用法，其实这个使用还是很多的，根据一段生产消费者程序，来说一说。一个栗子package com.pochi.juc;import java.util.concurrent.locks.Condition; import java.util.concurrent.locks.ReentrantLock;public class ReentrenLockProblem {
Java J.U.C 中 AQS 子类 ReentrantLock 源码分析（一）
Coder Yang
09-16 501
写文章不易，转载请标明出处。 同时，如果你喜欢我的文章，请关注我，让我们一起进步。 一、概述 对于 Java 中的 JUC 包大家应该都是非常熟悉的，JUC 的全称是 Java.util.concurrent ，翻译过来也就是 Java 并发编程工具类包，在这个包中有许多在我们并发编程过程中经常使用到的线程安全的容器类和同步锁等一些组件，而在这个包中很多的线程安全都是基于基础底层的 AQ...
ReentrantLock的实现原理
u012031408的专栏
03-21 1575
ReentrantLock是一个显示锁，实现基础都是AQS。所谓的AQS就是AbstractQueuedSynchronizer， AQS的作用 用来构建锁和同步工具的框架， ReentrantLock、CountDownLatch、Semaphore基础都是AQS AQS有个state变量，是int类型，使用了volatile修饰，AQS围绕state提供两种基本的获取和释放功能 Reen...
【十九】Java多线程J.U.C之ReentrantLock和Condition（ReentrantLock与Synchronized的区别）
Sid小杰的博客
01-10 255
ReentrantLock和Synchronized比较 优点： 1.ReentrantLock可以指定是公平锁还是非公平锁，默认是非公平锁。 而Synchronized只能是非公平锁，可能存在线程饥饿。 ReentrantLock构造器源码： /** * Creates an instance of {@code ReentrantLock}. * Thi...
ReentrantLock 源码解析
05-25
下面是ReentrantLock的源码解析： ReentrantLock的实现基于AbstractQueuedSynchronizer（简称AQS），AQS提供了一种同步框架，可以用来实现各种类型的同步器。ReentrantLock是AQS提供的其中一种同步器。 在...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值