Lock和ReentrankLock

最新推荐文章于 2025-03-20 16:13:39 发布

清纯男高中生

最新推荐文章于 2025-03-20 16:13:39 发布

阅读量306

点赞数

分类专栏：多线程文章标签： java

本文链接：https://blog.youkuaiyun.com/qq_52041753/article/details/124150205

版权

本文介绍了Java 1.5引入的Lock接口及其实现类ReentrantLock，相较于synchronized提供了更灵活的锁操作。Lock接口包括lock、lockInterruptibly、tryLock等方法，ReentrantLock内部使用AQS（AbstractQueuedSynchronizer）实现，具备公平锁和非公平锁。AQS维护了一个FIFO等待队列，通过CAS操作保证同步状态的原子性。Condition接口提供了线程间通信的能力，允许更精确的控制线程等待和唤醒。

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

Lock和ReentrankLockJDK

1.5中提供了锁的接口：java.util.concrrent.locks.lock，提供了ReentrankLock，ReentrankReadWriteLock实现类

Lock接口

Lock接口提供了比Synchronized方法更加灵活的锁的操作接口，可以具有很大的属性，支持多个相关Condition对象（线程间通信，Object方法提供的wait、notify、notifyAll）
Lock接口提供的方法操作：
在这里插入图片描述
1，Lock

void lock()

获取锁，如果锁被使用会一直阻塞直至获取到锁
2，lockInterruptibly()

void lockInterruptibly() throws InterruptedException

如果当前线程未被中断，则获取锁
如果锁可用，则获取锁，并立即返回，如果在加锁过程中发生了Interrupt中断操作，会抛出InterruptedException异常，并中断掉当前线程的加锁状态
3，tryLock()

boolean tryLock()

尝试获取锁，仅在调用是锁为空闲状态才获取锁，如果锁是可用的返回true，如果锁不可用，该方法会立即返回false
4，tryLock()

boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException

在指定时间内尝试性获取锁
5，unlock

void unlock()

释放锁，加锁和释放锁是成对出现的，对应于lock()、tryLock()、tryLock(xx)、lockInterruptibly()等操作，如果成功的话应该对应一个unlock操作，这样可以避免死锁或者资源的浪费
6，newCondition()

Condition newCondition()

返回绑定到Lock实例的新的Condition实例，可以进行线程间通信

AQS：

AQS（AbstractQueuedSynchronizer）是J.U.C下较复杂的一个类，提供了一个为实现依赖于先进先出 (FIFO) 等待队列的阻塞锁和相关同步器（信号量、事件，等等）提供一个框架。
在这里插入图片描述
通过上面查看类的子类的层级关系可知：AQS是CountdownLatch、ReentrankLock、ThreadPoolExecutor、ReentrankReadWriterLock和Semaphore是实现的基础。

AQS存在的必要性：
在这里插入图片描述
上图中体现AQS很重要的概念：“阻塞队列”，当线程无法获取资源时，提供一个FIFO类型的有序队列，用于维护所有处于“等待中”的线程

AQS核心字段：
主要有三个核心字段：

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

其中state是描述有多少个线程获取锁

state=0：表示锁第空闲状态
state>0：表示锁被占用
state<0:表示溢出

state在AQS中是一个很重要的属性，不管是独占锁还是共享锁，通过CAS操作该字段，
如果是独占锁，需要通过CAS将其从0变为1，标记加锁成功，
如果是共享锁，表示的是并发的线程数

head和tail加上CAS就构成了一个FIFO队列，是一个双向链表，每个节点是Node类型，通过双向队列来完成同步状态的管理，如果当前线程获取同步状态失败，AQS将会把当前线程以及等待的状态信息构建成一个节点Node并加入到同步队列中，同时会阻塞当前线程，当同步状态释放掉，会将处于队列首节点的线程唤醒，让该线程获取同步状态，在队列中节点用来保存同步状态的线程（thread），等待状态（waitStatus）和前驱节点（prev）和后继节点（next）

 static final class Node {
   
    /** 标记表示节点正在共享模式中等待 */
    static final Node SHARED = new Node();
    /** 标记表示节点正在独占模式下等待 */
    static final Node EXCLUSIVE = null;

    /** 
    * 表示线程已经被取消 
    * 同步队列中的线程因为超时或中断，需要从同步队列中取消。被取消的节点将不会有任何改变
    */
    static final int CANCELLED = 1;


    /** 
    * 后继节点的线程处于等待状态，而当前节点的线程如果释放了同步状态或者被取消，将会通知后
    * 继节点，使后继节点的线程得以运行 
    */
    static final int SIGNAL = -1;


    /** 
      * 节点在等待队列中，节点线程等待在Condition上，当其他线程对Condition调用了signal()方法 
     *  后，该节点将会中等待队列中转移到同步队列中，加入到对同步状态的获取 
     */
    static final int CONDITION = -2;


    /**
     * 下一次共享模式同步状态获取将会无条件的被传播下去
     */
    static final int PROPAGATE = -3;



    /**
     *   等待状态，仅接受如下状态中的一个值：
     *   SIGNAL:  -1
     *   CANCELLED:   1
     *   CONDITION:   -2
     *   PROPAGATE:   -3
     *   0:  初始化的值
     *
     * 对于正常的同步节点，它的初始化值为0，对于条件节点它的初始化的值是CONDITION。它使用
     * CAS进行修改。
     */
    volatile int waitStatus;

    /**
     *  前驱节点
     */
    volatile Node prev;

    /**
     * 后继节点
     */
    volatile Node next;

    /**
     * 获取同步状态的线程
     */
    volatile Thread thread;

    /**
     * 等待队列中的后继节点。如果当前节点是共享的，那么这个字段是一个SHARED常量，也就是说
     * 节点类型（独占和共享）和等待队列中的后继节点公用同一个字段
     */
    Node nextWaiter;

    /**
     * 如果节点在共享模式下等待则返回true
     */
    final boolean isShared() {
   
        return nextWaiter == SHARED;
    }

    /**
     * 获取前驱节点
     */
    final Node predecessor() throws NullPointerException {
   
        Node p = prev;
        if (p == null)
            throw new NullPointerException();
        else
            return p;
    }

    Node() {
   
    }

    Node(Thread thread, Node mode) {
    
        this.nextWaiter = mode;
        this.thread = thread;
    }

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

volatile int waitStatus:节点的等待状态，一个节点可能位于以下几种状态：
CANCELLED = 1
当前的线程被取消,节点操作因为超时或者对应的线程被interrupt。节点不应该留在此状态，一旦达到此状态将从CHL队列中踢出。
SIGNAL = -1
表示当前节点的后继节点包含的线程需要运行，也就是unpark.节点的继任节点是（或者将要成为）BLOCKED状态（例如通过LockSupport.park()操作），因此一个节点一旦被释放（解锁）或者取消就需要唤醒（LockSupport.unpack()）它的继任节点。
CONDITION = -2
当前节点在等待condition，也就是在condition队列中.表明节点对应的线程因为不满足一个条件（Condition）而被阻塞。PROPAGATE=-3当前场景下后续的acquireShared能够得以执行

当前节点在sync队列中，等待着获取锁
正常状态，新生的非CONDITION节点都是此状态。
非负值标识节点不需要被通知（唤醒）。
volatile Node prev;此节点的前一个节点。节点的waitStatus依赖于前一个节点的状态。
volatile Node next;此节点的后一个节点。后一个节点是否被唤醒（uppark()）依赖于当前节点是否被释放。
volatile Thread thread;节点绑定的线程。
Node nextWaiter;下一个等待条件（Condition）的节点，由于Condition是独占模式，因此这里有一个简单的队列来描述Condition上的线程节点。

节点（Node）是构成CHL的基础，同步器拥有首节点（head）和尾节点（tail）,没有成功获取同步状态的线程会构建成一个节点并加入到同步器的尾部。CHL的基本结构如下：
在这里插入图片描述

AQS同步器原理

基本的思想是表现为一个同步器，支持下面两个操作：
获取锁：首先判断当前状态是否允许获取锁，如果是就获取锁，阻塞操作或者获取失败，也就是说如果是独占锁就可能阻塞，如果是共享锁就可能失败。另外如果是阻塞线程，那么线程就需要进入阻塞队列。当状态位允许获取锁时就修改状态，并且如果进了队列就从队列中移除。

while(synchronization state does not allow acquire){
   
   enqueue current thread if not already queued;
   possibly block current thread;
}
dequeue current thread if it was queued;

释放锁:这个过程就是修改状态位，如果有线程因为状态位阻塞的话就唤醒队列中的一个或者更多线程。

update synchronization state;
if(state may permit a blocked thread to acquire)
   unlock one or more queued threads;

要支持上面两个操作就必须有下面的条件：
● 原子性操作同步器的状态位 state ->CAS
● 阻塞和唤醒线程？？？->JNI LockSupport类
● 一个有序的队列
目标明确，要解决的问题也清晰了，那么剩下的就是解决上面三个问题。

● 状态位的原子操作
这里使用一个32位的整数来描述状态位，使用CAS操作来修改状态。事实上这里还有一个64位版本的同步器（AbstractQueuedLongSynchronizer），这里暂且不谈。
● 阻塞和唤醒线程
标准的JAVA API里面是无法挂起（阻塞）一个线程，然后在将来某个时刻再唤醒它的。JDK 1.0的API里面有Thread.suspend和Thread.resume，并且一直延续了下来。但是这些都是过时的API，而且也是不推荐的做法。
在JDK 1.5以后利用JNI在LockSupport类中实现了此特性。
LockSupport.park()
LockSupport.park(Object)
LockSupport.parkNanos(Object, long)
LockSupport.parkNanos(long)
LockSupport.parkUntil(Object, long)
LockSupport.parkUntil(long)
LockSupport.unpark(Thread)
上面的API中park()是在当前线程中调用，导致线程阻塞，带参数的Object是挂起的对象，这样监视的时候就能够知道此线程是因为什么资源而阻塞的。由于park()立即返回，所以通常情况下需要在循环中去检测竞争资源来决定是否进行下一次阻塞。park()返回的原因有三：
● 其他某个线程调用将当前线程作为目标调用 unpark；
● 其他某个线程中断当前线程；
● 该调用不合逻辑地（即毫无理由地）返回。
其实第三条就决定了需要循环检测了，类似于通常写的while(checkCondition()){Thread.sleep(time);}类似的功能。

● 有序队列
在AQS中采用CHL列表来解决有序的队列的问题。
在这里插入图片描述
AQS采用的CHL模型采用下面的算法完成FIFO的入队列和出队列过程。
查看类的方法和属性

快捷键：comand(win)+7
非快捷键：类的顶部栏：View->Tool Windows->Structure

对于入队列(enqueue)：从数据结构上出发，入列是比较简单的，无非就是当前队列中的尾节点指向新节点，新节点的prev指向队列中的尾节点，然后将同步器的tail节点指向新节点。在AQS中入列的源码如下：

/**
 * 为当前线程和给定的模式创建节点并计入到同步队列中
 *
 * @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
 * @return the new node
 */
private Node addWaiter(Node mode) {
   
    // 创建一个节点
    Node node = new Node(Thread.currentThread(), mode);
    // 快速尝试添加尾节点，如果失败则调用enq(Node node)方法设置尾节点
    Node pred = tail;
    // 判断tail节点是否为空，不为空则添加节点到队列中
    if (pred != null) {
   
        node.prev = pred;
        // CAS设置尾节点
        if (compareAndSetTail(pred, node

最低0.47元/天解锁文章