【并发的艺术】--同步锁-ReentrantLock底层实现原理

本文详细探讨了ReentrantLock的工作原理,包括其与synchronized关键字的对比,非公平锁和公平锁的区别,以及如何在Java中使用ReentrantLock实现线程间的同步控制。

同步锁

锁是控制多个线程访问共享资源的方式,一个锁防止多个线程同时访问共享资源。

Lock接口出现之前,java程序只能依靠synchronized关键字来实现同步锁。在java5以后增加的JUC的并发包并且提供了lock接口用来实现锁的功能。提供与synchronized类似的功能,比synchronized更灵活,显示的获取和释放锁。


Lock锁的初步使用

Lock是一个接口,核心的两个方法lock和unlock,有很多的实现:ReentrantLock、ReentrantReadWriteLock;


ReentrantLock

重入锁,当前线程通过调用lock方法获取了锁之后,再次调用lock是不会再阻塞去获取锁的,直接增加重试次数就行了。


public class AtomicDemo {
    private static int count=0;
    static Lock lock=new ReentrantLock();
    public static void inc(){
        lock.lock();
        try {
            Thread.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
		count++;
        lock.unlock();
    }
    public static void main(String[] args) throws InterruptedException {
        for(int i=0;i<1000;i++){
            new Thread(()->{AtomicDemo.inc();}).start();;
        }
        Thread.sleep(3000);
        System.out.println("result:"+count);
    }
}
 



Lock和synchronized简单对比


1、直观的差异,一个是关键字,一个是类。

2、使用上,lock具备更大的灵活性,可以控制锁的释放和获取; 而synchronized的锁的释放是被动的,当出现 异常或者同步代码块执行完以后,才会释放锁。

3、lock可以判断锁的状态、而synchronized无法做到。

4、lock可以实现公平锁、非公平锁; 而synchronized只有非公平锁。



ReentrantLock的实现原理源码分析

独占锁

重入锁,分公平和不公平两种。

非公平锁实现的流程时序图:

屏幕快照 2019-07-23 上午10.04.42.png


源码

---获取锁--start---

ReentrantLock.lock

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


这个是获取锁的入口,调用了sync.lock; sync是一个实现了AQS的抽象类,这个类的主要作用是用来实现同步控制的,并且sync有两个实现,一个是NonfairSync(非公平锁)、另一个是FailSync(公平锁); 我们先来分析一下非公 平锁的实现。


NonfairSync.lock

 final void lock() {
    if (compareAndSetState(0, 1)) //这是跟公平锁的主要区别,一上来就试探锁是否空闲,如果可以插队,则设置获得锁的线程为当前线程。
      	//exclusiveOwnerThread属性是AQS从父类AbstractOwnableSynchronizer中继承的属性,用来保存当前占用 同步状态的线程
        setExclusiveOwnerThread(Thread.currentThread());
    else
        acquire(1); //尝试去获取锁
}

通过cas算法去改变state的值,而这个state是什么呢? 在AQS中存在一个变量state,对于ReentrantLock来说,如果state=0表示无锁状态、如果state>0表示 有锁状态。


AbstractQueuedSynchronizer.acquire


如果CAS操作未能成功,说明state已经不为0,此时继续acquire(1)操作,acquireAQS中的方法 当多个线程同时进 入这个方法时,首先通过cas去修改state的状态,如果修改成功表示竞争锁成功,竞争失败的,tryAcquire会返回false.


 public final void acquire(int arg) {
    if (!tryAcquire(arg) &&acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
		selfInterrupt();
}
/*
这个方法的主要作用是
Ø 尝试获取独占锁,获取成功则返回,否则
Ø 自旋获取锁,并且判断中断标识,如果中断标识为true,则设置线程中断 
Ø addWaiter方法把当前线程封装成Node,并添加到队列的尾部*/


NonfairSync.tryAcquire

tryAcquire方法尝试获取锁,如果成功就返回,如果不成功,则把当前线程和等待状态信息构适成一个Node节点,并将结点放入同步队列的尾部。然后为同步队列中的当前节点循环等待获取锁,直到成功.


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

Sync.nofairTryAcquire

 
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState(); //获取当前的状态,前面讲过,默认情况下是0表示无锁状态 
    if (c == 0) {
        if (compareAndSetState(0, acquires)) { //通过cas来改变state状态的值,如果更新成功,表 示获取锁成功, 这个操作外部方法lock()就做过一次,这里再做只是为了再尝试一次,尽量以最简单的方式获取锁。
                    setExclusiveOwnerThread(current);
                    return true;
            }
    }
    else if (current == getExclusiveOwnerThread()) {//如果当前线程等于获取锁的线程,表示重入, 直接累加重入次数
    	int nextc = c + acquires;
    	if (nextc < 0) // overflow 如果这个状态值越界,抛出异常;如果没有越界,则设置后返回true
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    如果状态不为0,且当前线程不是owner,则返回false。 
    return false; //获取锁失败,返回false
}


AQS.addWaiter


当前锁如果已经被其他线程锁持有,那么当前线程来去请求锁的时候,会进入这个方法,这个方法主要是把当前线程 封装成node,添加到AQS的链表中。


private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode); //创建一个独占的Node节点,mode为排他模式
    // 尝试快速入队,如果失败则降级至full enq
    Node pred = tail; // tail是AQS的中表示同步队列队尾的属性,刚开始为null,所以进行enq(node)方
    法
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) { // 防止有其他线程修改tail,使用CAS进行修改,如果失 败则降级至full enq
			pred.next = node; // 如果成功之后旧的tail的next指针再指向新的tail,成为双向链表
            return node;
        }
	}
	enq(node); // 如果队列为null或者CAS设置新的tail失败 
    return node;
}


enq

enq就是通过自旋操作把当前节点加入到队列中。

 
private Node enq(final Node node) {
    for (;;) { //无效的循环,为什么采用for(;;),是因为它执行的指令少,不占用寄存器
        Node t = tail;// 此时head, tail都为null
        if (t == null) { // Must initialize// 如果tail为null则说明队列首次使用,需要进行初始化
            if (compareAndSetHead(new Node()))// 设置头节点,如果失败则存在竞争,留至下一轮循环 tail = head; // 用CAS的方式创建一个空的Node作为头结点,因为此时队列中只一个头结
            点,所以tail也指向head,第一次循环执行结束 
        } else {
            //进行第二次循环时,tail不为null,进入else区域。将当前线程的Node结点的prev指向tail,然后使用CAS将 tail指向Node
            //这部分代码和addWaiter代码一样,将当前节点添加到队列
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node; //t此时指向tail,所以可以CAS成功,将tail重新指向CNode。此时t为更 新前的tail的值,即指向空的头结点,t.next=node,就将头结点的后续结点指向Node,返回头结点
                return t;
            }
        } 
    }
}

代码运行到这里,aqs队列的结构就是这样一个表现。



acquireQueued


 final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();// 获取prev节点,若为null即刻抛出 NullPointException
            if (p == head && tryAcquire(arg)) {// 如果前驱为head才有资格进行锁的抢夺 
                setHead(node); // 获取锁成功后就不需要再进行同步操作了,获取锁成功的线程作为新的head节点
                //凡是head节点,head.thread与head.prev永远为null, 但是head.next不为null
            	p.next = null; // help GC 
                failed = false; //获取锁成功 
                return interrupted;
            }
            //如果获取锁失败,则根据节点的waitStatus决定是否需要挂起线程
            if (shouldParkAfterFailedAcquire(p, node) &&parkAndCheckInterrupt())// 若前面为true,则执行挂起,待下次唤醒的时候检测中断的标志
                interrupted = true;
        }
    } finally {
        if (failed) // 如果抛出异常则取消锁的获取,进行出队(sync queue)操作
            cancelAcquire(node);
    } 
 }

原来的head节点释放锁以后,会从队列中移除,原来head节点的next节点会成为head节点。


shouldParkAfterFailedAcquire


 private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { int ws = pred.waitStatus; //前继节点的状态
    if (ws == Node.SIGNAL)//如果是SIGNAL状态,意味着当前线程需要被unpark唤醒
    return true; 如果前节点的状态大于0,即为CANCELLED状态时,则会从前节点开始逐步循环找到一个没有被“CANCELLED”节点设置 为当前节点的前节点,返回false。在下次循环执行shouldParkAfterFailedAcquire时,返回true。这个操作实 际是把队列中CANCELLED的节点剔除掉。
    if (ws > 0) {// 如果前继节点是“取消”状态,则设置 “当前节点”的 “当前前继节点” 为 “‘原前继节 点'的前继节点”。
            do {
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
    pred.next = node;
    } else { // 如果前继节点为“0”或者“共享锁”状态,则设置前继节点为SIGNAL状态。
            /*
             * waitStatus must be 0 or PROPAGATE.  Indicate that we
             * need a signal, but don't park yet.  Caller will need to
             * retry to make sure it cannot acquire before parking.
             */
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

解读:假如有t1,t2两个线程都加入到了链表中img

如果head节点位置的线程一直持有锁,那么t1t2就是挂起状态,而HEAD以及Thread1的的awaitStatus都是SIGNAL,在多次尝试获取锁失败以后,就会通过下面的方法进行挂起(这个地方就是避免了惊群效应,每个节点 只需要关心上一个节点的状态即可)

imgSIGNAL:值为-1,表示当前节点的的后继节点将要或者已经被阻塞,在当前节点释放的时候需要unpark后继节

点;CONDITION:值为-2,表示当前节点在等待condition,即在condition队列中;PROPAGATE:值为-3,表示releaseShared需要被传播给后续节点(仅在共享模式下使用);


parkAndCheckInterrupt

如果shouldParkAfterFailedAcquire返回了true,则会执行:“parkAndCheckInterrupt()”方法,它是通过LockSupport.park(this)当前线程挂起到WATING状态,它需要等待一个中断、unpark方法来唤醒它,通过这样一种FIFO的机制的等待,来实现了Lock的操作

 
private final boolean parkAndCheckInterrupt() {
    LockSupport.park(this);// LockSupport提供park()和unpark()方法实现阻塞线程和解除线程阻塞 
    return Thread.interrupted();
}


---获取锁--end---


---释放锁--start---

ReentrantLock.unlock

加锁的过程分析完以后,再来分析一下释放锁的过程,调用release方法,这个方法里面做两件事,

1,释放锁 ;

2,唤醒park的线程.


 
public final boolean release(int arg) {
    if (tryRelease(arg)) {//释放锁
        Node h = head;//AQS同步队列头节点
        if (h != null && h.waitStatus != 0)
            //唤醒节点中的线程
            unparkSuccessor(h);
        return true;
}
    return false;
}



tryRelease

这是设置锁状态的操作,将状态减掉传入的参数值(参数是1),如果结果状态为0, 就将排它锁的Owner设置为null,以使得其它的线程有机会进行执行。 在排它锁中,加锁的时候状态会增加1(当 然可以自己修改这个值),在解锁的时候减掉1,同一个锁,在可以重入后,可能会被叠加为234这些值,只有unlock()的次数与lock()的次数对应才会将Owner线程设置为空,而且也只有这种情况下才会返回true


protected final boolean tryRelease(int releases) {
    int c = getState() - releases; // 这里是将锁的数量减1
    if (Thread.currentThread() != getExclusiveOwnerThread())// 如果释放的线程和获取锁的线程 不是同一个,抛出非法监视器状态异常
    	throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        // 由于重入的关系,不是每次释放锁c都等于0,
        // 直到最后一次释放锁时,才会把当前线程释放 
        free = true;
            setExclusiveOwnerThread(null);
        }
    setState(c);
    return free;
}


private void unparkSuccessor(Node node) {
           int ws = node.waitStatus;
           if (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);
    }



LockSupport


public native void unpark(Thread jthread);
public native void park(boolean isAbsolute, long time);

unpark函数为线程提供许可(permit)”,线程调用park函数则等待许可。这个有点像信号量,但是这个许可是不 能叠加的,许可是一次性的。

permit相当于0/1的开关,默认是0,调用一次unpark就加1变成了1.调用一次park会消费permit,又会变成0。 如 果再调用一次park会阻塞,因为permit已经是0了。直到permit变成1.这时调用unpark会把permit设置为1.每个线 程都有一个相关的permitpermit最多只有一个,重复调用unpark不会累积

在使用LockSupport之前,我们对线程做同步,只能使用waitnotify,但是waitnotify其实不是很灵活,并且耦 合性很高,调用notify必须要确保某个线程处于wait状态,而park/unpark模型真正解耦了线程之间的同步,先后 顺序没有直接关联,同时线程之间不再需要一个Object或者其它变量来存储状态不再需要关心对方的状态

---释放锁--end---


公平锁和非公平锁的区别



非公平锁在获取锁的时候,会先通过CAS进行抢占,而公平锁则不会。


FairSync.tryAcquire


 final void** lock() {
     acquire(1);
}


FairSync.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;
         } 
     }
     else if (current == getExclusiveOwnerThread()) {
         int nextc = c + acquires;
         if (nextc < 0)
             throw new Error("Maximum lock count exceeded");
         setState(nextc);
         return true;
     }
     return false;
 }

这个方法与nonfairTryAcquire(int acquires)比较,不同的地方在于判断条件多了hasQueuedPredecessors()方 法,也就是加入了[同步队列中当前节点是否有前驱节点]的判断,如果该方法返回true,则表示有线程比当前线程 更早地请求获取锁,因此需要等待前驱线程获取并释放锁之后才能继续获取锁。


<think>我们正在讨论的是ReentrantLock底层实现原理和源码分析。根据用户提供的引用,ReentrantLock是基于AQS(AbstractQueuedSynchronizer)框架实现的,并且支持公平锁和非公平锁两种模式。下面我将从几个关键点展开分析: 1. **ReentrantLock的核心结构**: ReentrantLock内部有一个Sync类,它继承自AQS。Sync有两个子类:NonfairSync(非公平锁)和FairSync(公平锁)。默认情况下,ReentrantLock使用的是非公平锁。 2. **AQS框架**: AQS是构建锁和同步器的基础框架,它使用一个FIFO队列(CLH锁的变体)来管理等待线程,并通过一个volatile的int变量(state)表示同步状态。 3. **可重入性的实现**: ReentrantLock的可重入性是通过记录当前持有锁的线程以及重入次数(state)来实现的。每次重入,state就加1;释放锁时,每次释放state减1,直到state为0时,锁完全释放。 4. **公平锁与非公平锁的区别**: - 非公平锁(NonfairSync):线程尝试获取锁时,不管等待队列中是否有其他线程等待,直接尝试获取锁(通过CAS修改state)。如果获取失败,则加入队列等待。 - 公平锁(FairSync):线程尝试获取锁时,先检查等待队列中是否有线程在等待,如果有,则加入队列等待;否则才尝试获取锁。 5. **源码分析(以非公平锁为例)**: - 加锁(lock()方法): 1. 首先尝试通过CAS将state从0改为1(即获取锁)。 2. 如果成功,设置当前线程为独占线程。 3. 如果失败,则调用AQS的acquire(1)方法,该方法会再次尝试获取锁(tryAcquire),如果失败则将线程加入队列并挂起。 - 解锁(unlock()方法): 1. 调用Sync的release(1)方法,其中会调用tryRelease方法(由Sync实现)来释放锁(state减1)。 2. 如果state减为0,则释放锁,并唤醒等待队列中的下一个线程。 下面我们结合源码片段进行详细说明。 ### 1. 锁的获取(非公平锁) ```java // ReentrantLock.NonfairSync final void lock() { // 第一步:直接尝试CAS获取锁 if (compareAndSetState(0, 1)) setExclusiveOwnerThread(Thread.currentThread()); else // 如果失败,则调用AQS的acquire方法 acquire(1); } // AQS的acquire方法 public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); } // 非公平锁的tryAcquire实现 protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires); } // Sync中的nonfairTryAcquire方法 final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { // 再次尝试CAS获取锁(这里没有检查队列中是否有等待线程) if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } // 如果当前线程已经持有锁,则重入 else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0) // overflow throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; } ``` ### 2. 锁的释放 ```java // ReentrantLock.unlock() public void unlock() { sync.release(1); } // AQS的release方法 public final boolean release(int arg) { if (tryRelease(arg)) { Node h = head; if (h != null && h.waitStatus != 0) unparkSuccessor(h); return true; } return false; } // 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) { free = true; setExclusiveOwnerThread(null); } setState(c); return free; } ``` ### 3. 公平锁的获取 公平锁与非公平锁的主要区别在于`tryAcquire`方法中,公平锁会先检查队列中是否有等待线程: ```java // FairSync的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; } } else if (current == getExclusiveOwnerThread()) { // 重入部分与非公平锁相同 int nextc = c + acquires; if (nextc < 0) throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; } ``` ### 总结 - **可重入性**:通过记录持有锁的线程和重入次数(state)实现- **公平性**:公平锁在获取锁时先检查等待队列,非公平锁则直接尝试获取。 - **底层队列**:使用AQS的CLH变体队列(FIFO双向队列)管理等待线程。 通过以上分析,我们可以看到ReentrantLock底层实现依赖于AQS框架,通过状态变量(state)和线程等待队列(Node队列)来实现锁的获取和释放,同时通过Sync的子类实现了公平和非公平两种策略。 ### §§相关问题§§ 1. ReentrantLock的公平锁和非公平锁在性能上有什么区别? 2. 为什么非公平锁可能导致线程饥饿? 3. ReentrantLock与synchronized关键字相比有哪些优势? 4. ReentrantLock的Condition是如何实现的? 5. AQS框架除了ReentrantLock还应用在哪些并发工具中?</think>### ReentrantLock底层实现原理及源码分析 ReentrantLock是Java并发包中基于AQS(AbstractQueuedSynchronizer)框架实现的可重入互斥锁,其核心设计如下: --- #### 一、核心数据结构 1. **AQS同步器** ReentrantLock内部通过继承AQS的`Sync`类实现同步控制: ```java abstract static class Sync extends AbstractQueuedSynchronizer { // 实现tryAcquire/tryRelease等核心方法 } ``` - `state`字段:记录锁的重入次数(0表示未锁定,>0表示锁定状态) - `exclusiveOwnerThread`:记录当前持有锁的线程 2. **等待队列(CLH变体)** 采用虚拟双向FIFO队列管理等待线程,节点结构为: ```java static final class Node { volatile int waitStatus; // 等待状态(CANCELLED/SIGNAL等) volatile Node prev; // 前驱节点 volatile Node next; // 后继节点 volatile Thread thread; // 关联线程 } ``` --- #### 二、锁类型实现 1. **非公平锁(默认)** `NonfairSync`直接抢占资源: ```java final void lock() { if (compareAndSetState(0, 1)) // 尝试CAS直接获取锁 setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); // 进入AQS队列 } ``` - 特点:新线程可能插队,吞吐量高但可能引发饥饿 2. **公平锁** `FairSync`严格按队列顺序获取: ```java protected final boolean tryAcquire(int acquires) { if (!hasQueuedPredecessors()) { // 检查队列是否有等待线程 if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } return false; } ``` - 特点:保证先到先得,避免饥饿但性能较低 --- #### 三、可重入实现原理 通过记录持有线程和重入计数器实现: ```java final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } // 重入关键:当前线程已持有锁时增加计数 else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; // 重入次数+1 setState(nextc); return true; } return false; } ``` --- #### 四、加锁流程(以非公平锁为例) 1. 尝试CAS快速获取锁(`state` 0→1) 2. 失败后调用`acquire(1)`进入AQS队列 3. 在队列中自旋检查前驱节点状态 4. 前驱为头节点时再次尝试获取锁 5. 获取失败则通过`LockSupport.park()`挂起线程 --- #### 五、解锁流程 ```java public void unlock() { sync.release(1); // 调用AQS的release } protected final boolean tryRelease(int releases) { int c = getState() - releases; if (Thread.currentThread() != getExclusiveOwnerThread()) throw new IllegalMonitorStateException(); boolean free = false; if (c == 0) { // 完全释放锁 free = true; setExclusiveOwnerThread(null); } setState(c); // 更新重入计数 return free; } ``` - 释放后唤醒后继节点线程 - 完全释放(state=0)时清除持有线程标记 --- #### 六、与synchronized对比 | 特性 | ReentrantLock | synchronized | |--------------------|--------------------------------|----------------------| | 实现机制 | AQS+Java代码 | JVM内置monitor | | 公平性 | 支持公平/非公平 | 仅非公平 | | 条件变量 | 支持多个Condition | 单条件等待 | | 超时机制 | `tryLock(timeout)` | 不支持 | | 中断响应 | `lockInterruptibly()` | 不支持 | | 性能 | 高竞争场景更优 | 低竞争场景更优 | --- ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值