前面《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里面进行解锁，防止程序出现异常无法解锁
|
1
2
3
4
5
6
7
8
9
|
ReentrantLock lock = new ReentrantLock();lock.lock();try { System.out.println("获取了锁");} catch (Exception e) { e.printStackTrace();} finally { lock.unlock();} |
下面通过一个程序示例，演示一下ReentrantLock的使用：对同一个lock对象做多次加锁，解锁，演示一下ReentrantLock的锁重入
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
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("线程:--->"+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）。
|
1
2
3
|
public void lock() { sync.lock();} |
这里调用的是非公平锁，所以我们看下 NonFairSync的lock方法：进来时不管有没有其他线程持有锁或者等待锁，会先调用AQS中的compareAndSetState方法尝试获取锁，如果获取失败，会调用AQS中的acquire方法
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
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方法进行排队、阻塞等处理。
|
1
2
3
4
5
|
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt();} |
下面看下NonFairSync类中重写的tryAcquire方法，里面又调用了nonfairTryAcquire方法
|
1
2
3
|
protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires);} |
下面看下nonfairTryAcquire方法：
- 判断state如果为0，通过CAS的方式尝试获取锁，如果获取锁成功，则将当前线程设置为独占线程
- 如果state不为0，则判断当前线程是否跟独占线程时同一个线程，如果是同一个线程则将锁的state加1，也就是锁的重入次数加1
- 否则获取锁失败，返回false
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
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方法
|
1
2
3
|
public void unlock() { sync.release(1);} |
AQS中的release方法如下所示：会先调用AQS的子类Sync中重写的tryRelease方法去释放锁，如果是否锁成功，则唤醒同步队列中head的后续节点，后续节点线程被唤醒会去竞争锁。
|
1
2
3
4
5
6
7
8
9
|
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。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
/** * 释放锁 */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方法。
|
1
2
3
|
public void lock() { sync.lock();} |
FairSync的lock方法直接调用了AQS中的acquire方法，没有像非公平锁先通过CAS的方式先去尝试获取锁
|
1
2
3
|
final void lock() { acquire(1);} |
下面看下acquire方法，会先调用FairSync类中重写的tryAcquire方法尝试获取锁，如果获取锁失败会调用AQS中的acquireQueued方法进行排队、阻塞等处理。
|
1
2
3
4
5
|
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt();} |
下面看下FairSync类中重写的tryAcquire方法，这个方法跟NonFairSync的唯一区别就是state为0的时候，公平锁会先通过hasQueuedPredecessors()方法判断是否队列中是否有等待的节点，如果没有才会尝试通过CAS的方式去获取锁，非公平锁不会判断直接回尝试获取锁。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
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方法与非公平锁的代码一样，这里就不再介绍了。
到此这篇关于Java并发编程之ReentrantLock实现原理及源码剖析的文章就介绍到这了,更多相关Java ReentrantLock内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://blog.csdn.net/u012988901/article/details/112557666
