本文详细解析了ReentrantLock和ReentrantReadWriteLock的内部实现机制，包括公平锁与非公平锁的区别，以及读写锁的升级与降级过程。深入探讨了这两种锁如何在多线程环境下保证数据一致性。
一、ReentrantLock
ReentrantLock是可重入锁，已经获得锁的线程可以再次获得锁，如果一个线程获取了n个锁，那么释放的时候同样要释放n个锁。
同步组件主要是通过重写AQS的几个protected方法来表达自己的同步语义。ReentrantLock主要的方法：
//获取锁
public void lock() {
sync.lock();
}
//释放锁
public void unlock() {
sync.release(1);
}
可以看到都调用了syn的方法，syn是 ReentrantLock的抽象内部类，继承了AbstractQueuedSynchronizer。ReentrantLock里面大部分的功能都是委托给Sync来实现的，同时Sync内部定义了lock()抽象方法由其子类去实现。
unlock调用了AQS的release方法。FairSync（公平锁） 和NonfairSync（非公平锁）继承了Syn。
1、公平锁
（1）获取锁
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);//获取1个锁。该方法调用父类的，而父类又会调用子类覆写的tryAcquire方法
}
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();//1.获取当前线程
int c = getState();//2.获取同步状态
if (c == 0) {//3.1如果状态为0，表示没有获取过锁
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);//设置获得独占锁的线程为当前线程
return true;
}
}
//线程重入
else if (current == getExclusiveOwnerThread()) {//3.2状态大于0，表明锁被占用了，如果持有的线程是当前线程，直接加上获取锁的数目
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}/**在同步队列中是否有前驱节点的判断，如果有前驱节点说明有线程比当前线程更早的请求资源，根据公平性，当前线程请求资源失败*/
public final boolean hasQueuedPredecessors() {
Node t = tail;
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}（2）释放锁
参考3
2、非公平锁
（1）获取锁
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
final void lock() {
if (compareAndSetState(0, 1))//1.如果锁是空闲的，直接获取
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);//2.否则尝试获取锁，AQS会调用tryAcquire获取
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);//调用Syn的nonfairTryAcquire方法
}
} final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {//1.如果同步状态为0，直接获取锁
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {//2.线程重入
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}非公平锁和公平锁的不同之处在于公平锁会检查在同步队列中是否有线程比当前线程更早的请求资源，如果有就不允许获取锁，而非公平锁则不会检查，直接获取。公平锁每次都是从同步队列中的第一个节点获取到锁，而非公平性锁则不一定，有可能刚释放锁的线程能再次获取到锁。
（2）释放锁
参考3
3、释放锁
释放锁调用的是Syn的tryRelease方法
protected final boolean tryRelease(int releases) {
int c = getState() - releases;//1.减去释放的数量（reentranlock默认是减1）
if (Thread.currentThread() != getExclusiveOwnerThread())//如果当前线程不是持有锁的线程，抛出异常
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {//2.如果同步状态此时为0，说明已经被释放了
free = true;
setExclusiveOwnerThread(null);//重置持有锁线程记录
}
setState(c);//3.更新同步状态
return free;
}4、总结：
（摘自JAVA并发十：彻底理解ReentrantLock 作者：Java菜鸟奋斗史）
（1）公平锁每次获取到锁为同步队列中的第一个节点，保证请求资源时间上的绝对顺序，而非公平锁有可能刚释放锁的线程下次继续获取该锁，则有可能导致其他线程永远无法获取到锁，造成“饥饿”现象。
（2）公平锁为了保证时间上的绝对顺序，需要频繁的上下文切换，而非公平锁会降低一定的上下文切换，降低性能开销。因此，ReentrantLock默认选择的是非公平锁，则是为了减少一部分上下文切换，保证了系统更大的吞吐量。
（摘自《Java并发编程实战）
（3）即使对于公平锁，可轮询的trylock仍然会“插队”
（4）当持有锁的时间相对较长，或者请求锁的平均时间间隔较长，那么应该使用公平锁。在这些情况下，“插队”带来的吞吐量提升（当锁处于可用状态时，线程却还处于被唤醒的过程中）则可能不会出现
5、选择ReentrantLock还是synchronized？
（1）ReentrantLock的危险性比同步机制要高（如果忘记在finally块调用unlock）
（2）内置锁可以使用Thread Dump来监测死锁线程，便于调试，但JVM无法识别哪些线程持有ReentrantLock
（3）当需要一些高级功能时才应该使用ReentrantLock，比如：可定时的、可轮询的与可中断的锁获取操作，公平队列，以及非块结构的锁，否则，优先使用synchronized。
注意：两种机制如果混合使用，容易出错以及令人困惑
二、ReentrantReadWriteLock
ReentrantLock是独占锁，同一时刻只有一个线程能够获取，但在一些场景中大部分只是读数据，写数据很少，如果仅仅是读数据的话并不会影响数据正确性（出现脏读），读写锁允许同一时刻被多个读线程访问，但是在写线程访问时，所有的读线程和其他的写线程都会被阻塞。
先解析一下exclusiveCount方法，该方法返回锁被一个线程重复获取的次数。在ReentrantLock中使用一个int类型的state来表示同步状态，该值表示锁被一个线程重复获取的次数。ReentrantReadWriteLock中也是用int类型的state来表示同步状态，但是读写锁需要分别表示读状态和写状态，这个怎么办呢？
ReentrantReadWriteLock通过将state划分为高16位和低16位来分别维护读写状态，其中高16位维护的是读，低16位维护的是写。如下图所示（摘自深入理解读写锁—ReadWriteLock源码分析 作者： xingfeng_coder）
以写锁为例，可以看到EXCLUSIVE_MASK 是(1 << SHARED_SHIFT) - 1，也就是1左移16位-1，这时EXCLUSIVE_MASK=ox0000FFFF，而状态c&EXCLUSIVE_MASK，也就是保留了低16位，抹去高16位。
static final int SHARED_SHIFT = 16;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }再看看读锁是怎样的？ 读锁直接通过无符号右移16位，获得了高16位
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }1、写锁
（1）获取锁
protected final boolean tryAcquire(int acquires) {
/*
* Walkthrough:
* 1. If read count nonzero or write count nonzero
* and owner is a different thread, fail.
* 2. If count would saturate, fail. (This can only
* happen if count is already nonzero.)
* 3. Otherwise, this thread is eligible for lock if
* it is either a reentrant acquire or
* queue policy allows it. If so, update state
* and set owner.
*/
Thread current = Thread.currentThread();//1.获取当前线程
int c = getState();//2.获取同步状态
int w = exclusiveCount(c);//3.获取写锁获取次数
if (c != 0) {//4.1如果同步状态不为0，说明有线程已经获取更新了同步状态
// (Note: 如果 c != 0 and w == 0 then shared count != 0，读锁已被读线程获取)
if (w == 0 || current != getExclusiveOwnerThread())//当读锁已被读线程获取或者当前线程不是已经获取写锁的线程,获取失败
return false;
if (w + exclusiveCount(acquires) > MAX_COUNT)//超出了最大范围
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
setState(c + acquires);//获取成功，更新状态
return true;
}
//4.2 同步状态为0,
//在尝试获取同步状态之前先调用writerShouldBlock()是根据公平锁还是非公平锁来判断是否应该直接阻塞（也就是是否能够直接获取）
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))//设置状态
return false;
setExclusiveOwnerThread(current);//获取成功，设置获取锁的线程为当前线程
return true;
} static final class NonfairSync extends Sync {
private static final long serialVersionUID = -8159625535654395037L;
final boolean writerShouldBlock() {
return false; //直接返回false
}
final boolean readerShouldBlock() {
return apparentlyFirstQueuedIsExclusive(); //检查持锁线程的后继结点是否为写锁
}
}
/**
* Fair version of Sync
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -2274990926593161451L;
final boolean writerShouldBlock() {
return hasQueuedPredecessors();//检查是否有前继结点
}
final boolean readerShouldBlock() {
return hasQueuedPredecessors();//检查是否有前继结点
}
} /**
* 在非公平锁的实现中, 只要同步状态队列中有写线程正在等待的话, 就应该阻塞读线程, 不让其获取同步状态. 这样做是为了防止写线程出现饥饿现象.
*/
final boolean apparentlyFirstQueuedIsExclusive() {
Node h, s;
return (h = head) != null && //头结点是否为空
(s = h.next) != null && //后继结点是否为空
!s.isShared() && //后继是否是共享模式（读锁）
s.thread != null; //后继结点中的线程是否为空
}（2）释放锁
protected final boolean tryRelease(int releases) {
if (!isHeldExclusively())//1、判断是否是当前线程占有锁
throw new IllegalMonitorStateException();
int nextc = getState() - releases;//2、减去释放的数量
//3、当前写状态是否为0，为0则释放写锁
boolean free = exclusiveCount(nextc) == 0;
if (free)
setExclusiveOwnerThread(null);
//4、更新状态
setState(nextc);
return free;
}2、读锁
（1）HoldCounter、ThreadLocalHoldCounter
HoldCounter可以理解为是绑定线程上的一个计数器，而ThradLocalHoldCounter则是线程绑定的ThreadLocal。
/**
* 每个线程的读锁计数器
* 由ThreadLocal（ThreadLocalHoldCounter ）维护;缓存在cachedHoldCounter
*/
static final class HoldCounter {
int count = 0;//获取读锁数量
// Use id, not reference, to avoid garbage retention
final long tid = getThreadId(Thread.currentThread());//获取锁的线程id
}
/**
* 保存上一个成功获取读锁的线程的HoldCounter
*/
private transient HoldCounter cachedHoldCounter;
/** ThreadLocal子类，initialValue方法返回一个HoldCounter 实例 */
static final class ThreadLocalHoldCounter extends ThreadLocal<HoldCounter> {
public HoldCounter initialValue() {
return new HoldCounter();
}
}
/**
* 当前线程拥有的读锁数量。当读锁数量减至0时删除
*/
private transient ThreadLocalHoldCounter readHolds;（2）获取锁
protected final int tryAcquireShared(int unused) {
/*
* Walkthrough:
* 1. If write lock held by another thread, fail.
* 2. Otherwise, this thread is eligible for
* lock wrt state, so ask if it should block
* because of queue policy. If not, try
* to grant by CASing state and updating count.
* Note that step does not check for reentrant
* acquires, which is postponed to full version
* to avoid having to check hold count in
* the more typical non-reentrant case.
* 3. If step 2 fails either because thread
* apparently not eligible or CAS fails or count
* saturated, chain to version with full retry loop.
*/
Thread current = Thread.currentThread();
int c = getState();
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)//1.如果写锁不为0，且持有写锁的不是当前线程，说明其他线程持有写锁，不可获取读锁，返回-1
return -1;
int r = sharedCount(c);//获取读锁获取次数
//2.1如果成功获取了读锁
if (!readerShouldBlock() &&
r < MAX_COUNT &&
compareAndSetState(c, c + SHARED_UNIT)) {
if (r == 0) {//2.1.1 如果读锁未被持有
firstReader = current;//更新第一个获取读锁的线程
firstReaderHoldCount = 1;
} else if (firstReader == current) {//2.1.2 如果当前线程已经获取读锁
firstReaderHoldCount++;//持有锁数加1
} else {//2.1.3 其他线程拥有锁
HoldCounter rh = cachedHoldCounter;//更新最近成功获取读锁的HoldCounter
if (rh == null || rh.tid != getThreadId(current))//如果rh为空或rh内线程id不等于当前线程id
cachedHoldCounter = rh = readHolds.get();//更新缓存、rh
else if (rh.count == 0)//如果已获取读锁数量为0
readHolds.set(rh);//更新为当前线程
rh.count++;
}
return 1;
}
//2.2没有成功获取读锁
return fullTryAcquireShared(current);
} /**
* 获取读锁完整版本。处理CAS操作失败以及处理tryAcquireShared没有实现的可重入
*/
final int fullTryAcquireShared(Thread current) {
HoldCounter rh = null;
for (;;) {
int c = getState();
if (exclusiveCount(c) != 0) {
if (getExclusiveOwnerThread() != current)//其他线程持有写锁
return -1;
// else we hold the exclusive lock; blocking here
// would cause deadlock.
} else if (readerShouldBlock()) {
// Make sure we're not acquiring read lock reentrantly
if (firstReader == current) {//如果当前线程是第一个获取读锁的线程
// assert firstReaderHoldCount > 0;
} else {
if (rh == null) {
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current)) {
rh = readHolds.get();
if (rh.count == 0)
readHolds.remove();
}
}
if (rh.count == 0)
return -1;
}
}
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
if (compareAndSetState(c, c + SHARED_UNIT)) {//CAS更改状态，读锁加1
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) { //如果获取读锁的线程为第一次获取读锁的线程，则firstReaderHoldCount重入数 + 1
firstReaderHoldCount++;
} else {
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}（3）释放锁
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();//获取当前线程
//1.更新HoldCounter 和 ThreadLocalHoldCounter
if (firstReader == current) {//1.1如果想要释放锁的线程为第一个获取锁的线程，直接跳到第2步
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null;
else
firstReaderHoldCount--;
} else {//1.2否则，释放cachedHoldCounter存储线程获取的锁
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();//获取上一个获取读锁的线程的HoldCounter
int count = rh.count;
if (count <= 1) {
readHolds.remove();
if (count <= 0)
throw unmatchedUnlockException();
}
--rh.count;
}
//2.CAS更新状态
for (;;) {
int c = getState();
int nextc = c - SHARED_UNIT;
if (compareAndSetState(c, nextc))
// Releasing the read lock has no effect on readers,
// but it may allow waiting writers to proceed if
// both read and write locks are now free.
return nextc == 0;
}
}3、锁降级
锁降级是写锁降级为读锁，持有写锁的情况下获取读锁。
如果当前线程拥有写锁，然后将其释放，最后再获取读锁，这种分段完成的过程不能称之为锁降级。
以下是来自源码的一个demo：
从写锁降级成读锁，并不会自动释放当前线程获取的写锁，仍然需要显式的释放，否则别的线程永远也获取不到写锁。
public class CachedData {
Object data;
volatile boolean cacheValid;
final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
void processCachedData() {
rwl.readLock().lock();
if (!cacheValid) {
// Must release read lock before acquiring write lock
rwl.readLock().unlock();//必须先释放读锁
rwl.writeLock().lock();//获取写锁
try {
// 获取写锁后需要重新检查状态，因为其他线程可能在我们检查完状态还没获取锁前已经获取写锁并修改状态了
if (!cacheValid) {
data = "Datahahaha";
cacheValid = true;
}
// Downgrade by acquiring read lock before releasing write lock
rwl.readLock().lock();//锁降级。之所以要先获取读锁再释放写锁是因为如果先释放写锁，有可能因为其他线程获取了写锁导致读锁无法获取
} finally {
rwl.writeLock().unlock(); // 释放写锁，此时仍然持有读锁
}
}
try {
use(data);
} finally {
rwl.readLock().unlock();
}
}
private void use(Object data2) {
}
}
4、总结
读写锁只能降级，不能升级（同一个线程中，在没有释放读锁的情况下，就去申请写锁），很容易造成死锁（如果两个读线程试图同时升级为写入锁，那么二者都不会释放读锁）。
扫一扫
430
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
