|
| 1 | + |
| 2 | + |
| 3 | +# 1. ReentrantLock的介绍 # |
| 4 | +ReentrantLock重入锁,是实现Lock接口的一个类,也是在实际编程中使用频率很高的一个锁,**支持重入性,表示能够对共享资源能够重复加锁,即当前线程获取该锁再次获取不会被阻塞**。在java关键字synchronized隐式支持重入性(关于synchronized可以[看这篇文章](https://juejin.im/post/5ae6dc04f265da0ba351d3ff)),synchronized通过获取自增,释放自减的方式实现重入。与此同时,ReentrantLock还支持**公平锁和非公平锁**两种方式。那么,要想完完全全的弄懂ReentrantLock的话,主要也就是ReentrantLock同步语义的学习:1. 重入性的实现原理;2. 公平锁和非公平锁。 |
| 5 | + |
| 6 | +# 2. 重入性的实现原理 # |
| 7 | + |
| 8 | +要想支持重入性,就要解决两个问题:**1. 在线程获取锁的时候,如果已经获取锁的线程是当前线程的话则直接再次获取成功;2. 由于锁会被获取n次,那么只有锁在被释放同样的n次之后,该锁才算是完全释放成功。**通过[这篇文章](https://juejin.im/post/5aeb07ab6fb9a07ac36350c8),我们知道,同步组件主要是通过重写AQS的几个protected方法来表达自己的同步语义。针对第一个问题,我们来看看ReentrantLock是怎样实现的,以非公平锁为例,判断当前线程能否获得锁为例,核心方法为nonfairTryAcquire: |
| 9 | + |
| 10 | + |
| 11 | + final boolean nonfairTryAcquire(int acquires) { |
| 12 | + final Thread current = Thread.currentThread(); |
| 13 | + int c = getState(); |
| 14 | + //1. 如果该锁未被任何线程占有,该锁能被当前线程获取 |
| 15 | + if (c == 0) { |
| 16 | + if (compareAndSetState(0, acquires)) { |
| 17 | + setExclusiveOwnerThread(current); |
| 18 | + return true; |
| 19 | + } |
| 20 | + } |
| 21 | + //2.若被占有,检查占有线程是否是当前线程 |
| 22 | + else if (current == getExclusiveOwnerThread()) { |
| 23 | + // 3. 再次获取,计数加一 |
| 24 | + int nextc = c + acquires; |
| 25 | + if (nextc < 0) // overflow |
| 26 | + throw new Error("Maximum lock count exceeded"); |
| 27 | + setState(nextc); |
| 28 | + return true; |
| 29 | + } |
| 30 | + return false; |
| 31 | + } |
| 32 | + |
| 33 | +这段代码的逻辑也很简单,具体请看注释。为了支持重入性,在第二步增加了处理逻辑,如果该锁已经被线程所占有了,会继续检查占有线程是否为当前线程,如果是的话,同步状态加1返回true,表示可以再次获取成功。每次重新获取都会对同步状态进行加一的操作,那么释放的时候处理思路是怎样的了?(依然还是以非公平锁为例)核心方法为tryRelease: |
| 34 | + |
| 35 | + protected final boolean tryRelease(int releases) { |
| 36 | + //1. 同步状态减1 |
| 37 | + int c = getState() - releases; |
| 38 | + if (Thread.currentThread() != getExclusiveOwnerThread()) |
| 39 | + throw new IllegalMonitorStateException(); |
| 40 | + boolean free = false; |
| 41 | + if (c == 0) { |
| 42 | + //2. 只有当同步状态为0时,锁成功被释放,返回true |
| 43 | + free = true; |
| 44 | + setExclusiveOwnerThread(null); |
| 45 | + } |
| 46 | + // 3. 锁未被完全释放,返回false |
| 47 | + setState(c); |
| 48 | + return free; |
| 49 | + } |
| 50 | + |
| 51 | +代码的逻辑请看注释,需要注意的是,重入锁的释放必须得等到同步状态为0时锁才算成功释放,否则锁仍未释放。如果锁被获取n次,释放了n-1次,该锁未完全释放返回false,只有被释放n次才算成功释放,返回true。到现在我们可以理清ReentrantLock重入性的实现了,也就是理解了同步语义的第一条。 |
| 52 | + |
| 53 | +# 3. 公平锁与公平锁 # |
| 54 | +ReentrantLock支持两种锁:**公平锁**和**非公平锁**。**何谓公平性,是针对获取锁而言的,如果一个锁是公平的,那么锁的获取顺序就应该符合请求上的绝对时间顺序,满足FIFO**。ReentrantLock的构造方法无参时是构造非公平锁,源码为: |
| 55 | + |
| 56 | + public ReentrantLock() { |
| 57 | + sync = new NonfairSync(); |
| 58 | + } |
| 59 | + |
| 60 | +另外还提供了另外一种方式,可传入一个boolean值,true时为公平锁,false时为非公平锁,源码为: |
| 61 | + |
| 62 | + public ReentrantLock(boolean fair) { |
| 63 | + sync = fair ? new FairSync() : new NonfairSync(); |
| 64 | + } |
| 65 | + |
| 66 | +在上面非公平锁获取时(nonfairTryAcquire方法)只是简单的获取了一下当前状态做了一些逻辑处理,并没有考虑到当前同步队列中线程等待的情况。我们来看看公平锁的处理逻辑是怎样的,核心方法为: |
| 67 | + |
| 68 | + protected final boolean tryAcquire(int acquires) { |
| 69 | + final Thread current = Thread.currentThread(); |
| 70 | + int c = getState(); |
| 71 | + if (c == 0) { |
| 72 | + if (!hasQueuedPredecessors() && |
| 73 | + compareAndSetState(0, acquires)) { |
| 74 | + setExclusiveOwnerThread(current); |
| 75 | + return true; |
| 76 | + } |
| 77 | + } |
| 78 | + else if (current == getExclusiveOwnerThread()) { |
| 79 | + int nextc = c + acquires; |
| 80 | + if (nextc < 0) |
| 81 | + throw new Error("Maximum lock count exceeded"); |
| 82 | + setState(nextc); |
| 83 | + return true; |
| 84 | + } |
| 85 | + return false; |
| 86 | + } |
| 87 | + } |
| 88 | + |
| 89 | +这段代码的逻辑与nonfairTryAcquire基本上一直,唯一的不同在于增加了hasQueuedPredecessors的逻辑判断,方法名就可知道该方法用来判断当前节点在同步队列中是否有前驱节点的判断,如果有前驱节点说明有线程比当前线程更早的请求资源,根据公平性,当前线程请求资源失败。如果当前节点没有前驱节点的话,再才有做后面的逻辑判断的必要性。**公平锁每次都是从同步队列中的第一个节点获取到锁,而非公平性锁则不一定,有可能刚释放锁的线程能再次获取到锁**。 |
| 90 | + |
| 91 | +> **公平锁 VS 非公平锁** |
| 92 | + |
| 93 | +1. 公平锁每次获取到锁为同步队列中的第一个节点,**保证请求资源时间上的绝对顺序**,而非公平锁有可能刚释放锁的线程下次继续获取该锁,则有可能导致其他线程永远无法获取到锁,**造成"饥饿"现象**。 |
| 94 | + |
| 95 | +2. 公平锁为了保证时间上的绝对顺序,需要频繁的上下文切换,而非公平锁会降低一定的上下文切换,降低性能开销。因此,ReentrantLock默认选择的是非公平锁,则是为了减少一部分上下文切换,**保证了系统更大的吞吐量**。 |
| 96 | + |
| 97 | + |
| 98 | +> 参考文献 |
| 99 | + |
| 100 | + |
| 101 | +《java并发编程的艺术》 |
0 commit comments