Java并发编程之ReentrantLock实现原理及源码剖析

java并发编程之ReentrantLock实现原理及源码剖析

目录一、ReentrantLock简介二、ReentrantLock使用三、ReentrantLock源码分析1、非公平锁源码分析2、公平锁源码分析

前面《java并发编程之JUC并发核心AQS同步队列原理剖析》介绍了AQS的同步等待队列的实现原理及源码分析，这节我们将介绍一下基于AQS实现的ReentranLock的应用、特性、实现原理及源码分析。

一、ReentrantLock简介

ReentrantLock位于Java的juc包里面，从JDK1.5开始出现，是基于AQS同步队列的独占模式实现的一种锁。ReentrantLock使用起来比synchronized更加灵活，可以自己控制加锁、解锁的逻辑。ReentrantLock跟synchronized一样也是可重入的锁，提供了公平/非公平两种模式：

公平锁：多个线程竞争锁的时候，会先判断等待队列中是否有等待的线程节点，如果有则当前线程会进行排队，锁的获取顺序符合请求的绝对时间顺序，也就是 FIFO

非公平锁：当前线程竞争锁的时候不管有没有其他线程节点在排队，都会先通过CAS尝试获取锁，获取失败了才会进行排队。

通过new ReentrantLock()的方式创建的是非公平锁，要想创建公平锁需要在构造方法中指定new ReentrantLock(true)。ReentrantLock的常用方法如下：

void lock() 获取锁，如果当前线程获取锁成功将返回，获取锁失败线程将被阻塞、挂起

void lockInterruptibly() throws InterruptedException 可中断的获取锁，和lock方法的不同之处在于该方法会响应中断，即在锁的获取过程中可以中断当前线程

boolean tryLock() 尝试非阻塞的获取锁，方法会立即返回，获取锁成功返回true，否则返回false

boolean tryLock(long time, TimeUnit unit) throws InterruptedException 尝试在指定超时时间内获取锁，如果当前线程获取了锁会立即返回true，如果被其他线程获取了锁则会被阻塞挂起，该方法会在下面三种情况下返回：1，在超时时间内获取了锁，返回true；2，在超时时间内线程被中断；3，超时时间结束，返回false。

void unlock() 释放锁

Condition newCondition() 获取等待通知组件，该组件与当前的锁绑定，当前线程只有获取了锁，才能调用Condition的wait()方法，调用wait（）方法后会释放锁

二、ReentrantLock使用

ReentrantLock的使用方式一般如下，一定要在finally里面进行解锁，防止程序出现异常无法解锁

ReentrantLock lock = new ReentrantLock();

lock.lock();

try {

System.out.println("获取了锁");

} catch (Exception e) {

e.printStackTrace();

} finally {

lock.unlock();

}

下面通过一个程序示例，演示一下ReentrantLock的使用：对同一个lock对象做多次加锁，解锁，演示一下ReentrantLock的锁重入

public class ReentrantLockTest {

private Integer counter = 0;

private ReentrantLock lock = new ReentrantLock();

public void modifyResources(String threadName){

System.out.println("线程:--->"+threadName+"等待获取锁");

lock.lock();

System.out.println("线程:--->"+threadName+"第一次加锁");

counter++;

System.out.println("线程:"+threadName+"做第"+counter+"件事");

//重入该锁,我还有一件事情要做,没做完之前不能把锁资源让出去

lock.lock();

System.out.println("线程:--->http://"+threadName+"第二次加锁");

counter++;

System.out.println("线程:"+threadName+"做第"+counter+"件事");

lock.unlock();

System.out.println("线程:"+threadName+"释放一个锁");

lock.unlock();

System.out.println("线程:"+threadName+"释放一个锁");

}

public static void main(String[] args) throws InterruptedException {

ReentrantLockTest tp = new ReentrantLockTest();

new Thread(()->{

String threadName = Thread.currentThread().getName();

tp.modifyResources(threadName);

},"Thread:张三").start();

new Thread(()->{

String threadName = Thread.currentThread().getName();

tp.modifyResources(threadName);

},"Thread:李四").start();

Thread.sleep(100);

}

}

程序运行输出如下所示：上面代码中lock加锁两次然后解锁两次，在张三线程两次解锁完成之前，李四线程一直在等待。ReentrantLock加锁了几次，就要解锁相同的次数才可以释放锁。

线程:--->Thread:张三等待获取锁

线程:--->Thread:张三第一次加锁

线程:Thread:张三做第1件事

线程:--->Thread:张三第二次加锁

线程:--->Thread:李四等待获取锁

线程:Thread:张三做第2件事

线程:Thread:张三释放一个锁

线程:Thread:张三释放一个锁

线程:--->Thread:李四第一次加锁

线程:Thread:李四做第3件事

线程:--->Thread:李四第二次加锁

线程:Thread:李四做第4件事

线程:Thread:李四释放一个锁

线程:Thread:李四释放一个锁

三、ReentrantLock源码分析

ReentrantLock实现了Lock接口，它有一个内部类Sync实现了前面介绍过的AbstractQueuedSynchronizer，而其公平锁、非公平锁分别通过Sync的子类FairSync、NonFairSync（也是ReentrantLock的内部类）实现。下面看下其UML图

lock()方法调用时序图如下：

前面《Java并发编程之JUC并发核心AQS同步队列原理剖析》介绍AQS的时候说过，AbstractQueuedSynchronizer中有一个状态变量state，在ReentrantLock中state等于0表示没有线程获取锁，如果等于1说明有线程获取了锁，如果大于1说明获取锁的线程加锁的次数，加了几次锁就必须解锁几次，每次unlock解锁state都会减1，减到0时释放锁。

1、非公平锁源码分析

前面一篇博客《Java并发编程之JUC并发核心AQS同步队列原理剖析》对AQS介绍的已经非常详细了，所以下面源码分析中牵涉AQS中的方法就不再进行介绍了，想了解的话可以看下那篇博客。

先看下非公平锁的加锁lock方法，lock方法中调用了sync的lock方法，而sync对象时根据构造ReentrantLock时是公平锁（FairSync）还是非公平锁（NonFairSync）。

public void lock() {

sync.lock();

}

这里调用的是非公平锁，所以我们看下 NonFairSync的lock方法：进来时不管有没有其他线程持有锁或者等待锁，会先调用AQS中的compareAndSetState方法尝试获取锁，如果获取失败，会调用AQS中的acquire方法

final void lock() {

/**

* 第一步：直接尝试加锁

* 与公平锁实现的加锁行为一个最大的区别在于，此处不会去判断同步队列(CLH队列)中

* 是否有排队等待加锁的节点，上来直接加锁（判断state是否为0,CAS修改state为1）

* ，并将独占锁持有者 exclusiveOwnerThread 属性指向当前线程

* 如果当前有人占用锁，再尝试去加一次锁

*/

if (compareAndSetState(0, 1))

setExclusiveOwnerThread(Thread.currentThread());

else

//AQS定义的方法,加锁

acquire(1);

}

下面看下acquire方法，会先调用NonFairSync类中重写的tryAcquire方法尝试获取锁，如果获取锁失败会调用AQS中的acquireQueued方法进行排队、阻塞等处理。

public final void acquire(int arg) {

if (!tryAcquire(arg) &&

acquireQueued(addWaiter(Node.EXCLUSIVE), arg))

selfInterrupt();

}

下面看下NonFairSync类中重写的tryAcquire方法，里面又调用了nonfairTryAcquire方法

protected final boolean tryAcquire(int acquires) {

return nonfairTryAcquire(acquires);

}

下面看下nonfairTryAcquire方法：

判断state如果为0，通过CAS的方式尝试获取锁，如果获取锁成功，则将当前线程设置为独占线程

如果state不为0，则判断当前线程是否跟独占线程时同一个线程，如果是同一个线程则将锁的state加1，也就是锁的重入次数加1

否则获取锁失败，返回false

final boolean nonfairTryAcquire(int acquires) {

//acquires = 1

final Thread current = Thread.currentThread();

int c = getState();

/**

* 不需要判断同步队列（CLH）中是否有排队等待线程

* 判断state状态是否为0，不为0可以加锁

*/

if (c == 0) {

//unsafe操作，cas修改state状态

if (compareAndSetState(0, acquires)) {

//独占状态锁持有者指向当前线程

setExclusiveOwnerThread(current);

return true;

}

}

/**

* state状态不为0，判断锁持有者是否是当前线程，

* 如果是当前线程持有 则state+1

*/

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;

}

下面看下非公平锁的解锁过程：unlock方法中调用了AQS中的release方法

public void unlock() {

sync.release(1);

}

AQS中的release方法如下所示：会先调用AQS的子类Sync中重写的tryRelease方法去释放锁，如果是否锁成功，则唤醒同步队列中head的后续节点，后续节点线程被唤醒会去竞争锁。

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方法：

获取当前的state值，然后减1

判断当前线程是否是锁的持有线程，如果不是会抛出异常。

如果state的值被减到了0，表示锁已经被释放，会将独占线程设置为空null，将state设置为0，返回true，否则返回false。

/**

* 释放锁

*/

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;

}

2、公平锁源码分析

先看下公平锁的加锁lock方法，lock方法中调用了sync的lock方法，这里调用的是FairSync的lock方法。

public void lock() {

sync.lock();

}

FairSync的lock方法直接调用了AQS中的acquire方法，没有像非公平锁先通过CAS的方式先去尝试获取锁

final void lock() {

acquire(1);

}

下面看下acquire方法，会先调用FairSync类中重写的tryAcquire方法尝试获取锁，如果获取锁失败会调用AQS中的acquireQueued方法进行排队、阻塞等处理。

public final void acquire(int arg) {

if (!tryAcquire(arg) &&

acquireQueued(addWaiter(Node.EXCLUSIVE), arg))

selfInterrupt();

}

下面看下FairSync类中重写的tryAcquire方法，这个方法跟NonFairSync的唯一区别就是state为0的时候，公平锁会先通过hasQueuedPredecessors()方法判断是否队列中是否有等待的节点，如果没有才会尝试通过CAS的方式去获取锁，非公平锁不会判断直接回尝试获取锁。

protected final boolean tryAcquire(int acquires) {

final Thread current = Thread.currentThread();

int c = getState();

if (c == 0) {

/**

* 与非公平锁中的区别，需要先判断队列当中是否有等待的节点

* 如果没有则可以尝试CAS获取锁

*/

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;

}

公平锁的unlock方法与非公平锁的代码一样，这里就不再介绍了。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。