ReentrantReadWriteLock ，可重入读写锁。实际使用场景中，我们需要处理的操作本质上是读与写。而对这两种操作进行同步操作的难度也是不一样的。
一般情况下，读操作不会造成同步安全问题，因为只是读取数据而不去修改的情况下相当于数据是不可变的，不可变本质上是绝对的线程安全，无需进行任何确保线程安全的操作。
而如果在一系列操作中包含了写操作，那么就需要考虑线程安全了。在 JMM 中，写操作本质上是将主内存中的数据复制到线程的工作内存，然后进行更新，最后同步到主内存。如果此时有其他线程执行读操作，可能会读取到更新前到旧数据，就会造成数据不一致问题。
JMM 中定义的对写操作的执行流程中，要先去主内存读取数据，也就是说，一个写操作前一定包含了一个读操作，再算上其他的读操作场景，可以得出结论，在实际的使用场景中，读操作一定是多于写操作的。
按照上面的说法，好像读操作我们不需要进行线程安全处理，因为它本身就是线程安全的，那么为什么会有读写锁，尤其是读锁这种东西存在呢？
试想一个场景，多个线程读取一个共享资源，其中某个或某些线程在不确定的时间点会进行写操作，那么所有线程的读取到的数据是安全的吗？答案是不安全，因为写操作写入主内存不及时的话，后续其他线程的读操作读取到的数据就是主内存更新前的旧数据，就会导致脏数据问题。也就是说，写操作需要保证线程安全，并且是独占锁资源的，不能再写操作执行时，存在其他线程去执行读操作。那么就需要读锁与写锁配合处理同步逻辑。
常规的保证线程安全的方法就是普通的互斥锁，互斥锁会被一个线程持有，对其他线程造成阻塞。如果对一段有读操作也有写操作的代码使用互斥锁的话，对于争用这个共享数据的所有线程来说，只有一个拥有锁的线程可以正常运行，其他线程的逻辑即使是都是读操作。其他线程会阻塞等待锁资源。
读写锁的优势就是，在上面这种情况下，确保写操作的互斥性，并在没有写操作的场景下，读操作可以让多个线程同时获取锁资源。
ReadWriteLockReentrantReadWriteLock 是基于 AbstractQueuedSynchronizer 并实现了 ReadWriteLock 接口实现的一个锁机制。ReadWriteLock 定义了读写锁的特性：
ReadWriteLock 中定义了获取两种锁的方式，一个用于获取读锁、一个用于获取写锁。只要没有持有写锁的线程在执行，读锁可以同时被多个尝试读操作的线程持有，而写锁是排他锁。
与互斥锁相比，读写锁在访问共享数据时允许更高级的并发特性，即每次只有一个线程可以执行写操作，并且在没有写操作时其他线程可以并发读取共享数据。从读操作的效率来看，如果是互斥锁每次只能一个线程执行读写操作，而读写锁可以多个线程读，写操作时才互斥，所以读写锁的执行效率更高。
ReentrantReadWriteLock 源码分析前面的内容介绍了读写锁的含义和优势，接下来分析 Java 并发包中对它的实现 ReentrantReadWriteLock 。
类关系ReentrantReadWriteLock 实现了读写锁接口 ReadWriteLock 和序列化接口 Serializable 。
它有一个抽象静态内部类 Sync ，Sync 是 AQS 的抽象子类，Sync 有两个静态实现 NonfairSync 和 FairSync ，这部分是锁逻辑的核心内容；Sync 还有两个内部数据结构类 HoldCounter 和 ThreadLocalHoldCounter 。
ReadLock 和 WriteLock 分别对应了读锁和写锁，它们都实现了 Lock 接口和序列号接口 Serializable 。它们是 ReentrantReadWriteLock 中对不同操作的锁类型的实现，使用了装饰模式，本质上还是通过 Sync 的能力实现的。
Sync核心逻辑是来自于 Sync 及其两个实现，Sync 继承自 AbstractQueuedSynchronizer ，自身有两个内部类 HoldCounter 和 ThreadLocalHoldCounter 。
HoldCounterHoldCounter 是一个计数器，count 用来记录当前线程拥有读锁的数量，即读锁的重入次数；tid 用来记录当前线程唯一 ID 。
Sync 有一个 cachedHoldCounter 属性，用来做缓存效果，避免每次都通过 ThreadLocal 去读取数据。
ThreadLocalHoldCounterThreadLocalHoldCounter 重写了 ThreadLocal 的 initialValue() ，在 ThreadLocal 没有进行过 set 数据的情况下，默认读取到的值都来自于这个方法，也就是配合 ThreadLocal 使用，默认值返回一个新的 HoldCounter 实例。
在 Sync 中，有一个属性 readHolds ，它的类型是 ThreadLocalHoldCounter ，用来做当前线程读锁重入计数器的 ThreadLocal 包装，便于线程读取自己的读锁重入计数器。
属性Sync 中定义的属性包括：
构造方法Sync 初始化方法创建了 ThreadLocalHoldCounter 并重新设置了 State ，为什么要重新设置呢？因为这里要读取当前线程最新的同步状态并重新设置，获取实时的同步状态。
核心方法Sync 的关键方法包括：
锁的计数方法首先是两个静态方法 sharedCount(int c) 和 exclusiveCount(int c) ：
参数 c 是 AQS 中的 state，根据 state 进行位运算。这两个方法可以根据锁自身的状态解析出持有读写锁的数量。
sharedCount ，表示占有读锁的线程数量。直接将 AQS 中的 state 右移 16 位，高位补 0，就可以得到读锁的线程数量，因为 state 的高十六位表示读锁，对应的低十六位表示写锁数量。exclusiveCount，表示占有写锁的线程数量。直接将 AQS 的 state 和 (2^16 - 1) 做与运算，其等效于将 state 模上 2^16 。写锁数量由 state 的低十六位表示。 读写锁阻塞检查方法第二组方法是 readerShouldBlock 和 writerShouldBlock ，用来检查当前的读锁/写锁是否会造成当前线程阻塞。
这两个方法的实现在 Sync 的子类中 -- 公平策略实现 FairSync 和非公平策略实现 NonfairSync。
公平策略实现 FairSync 和非公平策略实现 NonfairSync公平锁策略和非公平锁策略的实现，本质上的不同是这两个方法的实现。
NonfairSync 非公平策略NonfairSync 中，执行写操作的线程是否应该进入阻塞状态的判断，直接是 false ，这是因为非公平策略下，如果当前自身已经拥有了写锁，直接重入，以独占的方式继续运行（所以是不公平的）。
执行读操作的线程是否会阻塞，是通过 apparentlyFirstQueuedIsExclusive() 判断的，这个方法是 AQS 中的方法：
这个方法的作用是，CLH 队列中的头节点和它的的 next 都存在的情况下，如果 next 节点不是 SharedNode ，且它的关联线程不为空的情况（即下一个锁不是共享锁，共享锁在读写锁里就是读锁）的情况，会导致当前执行读操作的线程进入阻塞状态，确保写操作的互斥特性。
FairSync 公平策略FairSync 中，读写执行线程是否应该进入阻塞状态都是根据 hasQueuedPredecessors() 方法判断的：
hasQueuedPredecessors() 对 head 节点和它的 next 节点进行空检查，并检查下一个节点的执行线程和 prev 指针是否有值，满足条件的情况下通过 getFirstQueuedThread() 方法获取到队列中第一个节点关联的线程。最终返回的结过是检查这个线程不等于当前线程。
如果存在等待队列第一个等待执行的线程，那么就优先执行这个线程。也就是说，不管当前线程是拥有读锁还是写锁，都优先执行等待队列第一个未执行节点，这里就能体现出公平，即优先执行等待队列中头一个等待的节点所关联的线程。
Release 和 Acquire 方法组这一组方法是整个 Sync 的核心逻辑，也是加解锁核心逻辑。
tryRelease：
tryRelease(int releases) 用来尝试释放写锁。
它的逻辑如下图：
tryAcquire：
此函数用于获取写锁，首先会获取 state ，判断 state 是否为0。
若为0，表示此时没有读锁线程，再判断写线程是否应该被阻塞，而在非公平策略下总是不会被阻塞，在公平策略下会进行判断(判断同步队列中是否有等待时间更长的线程，若存在，则需要被阻塞，否则，无需阻塞)，之后在设置状态state，然后返回true。若state不为0，则表示此时存在读锁或写锁线程，若写锁线程数量为0或者当前线程为独占锁线程，则返回false，表示不成功，否则，判断写锁线程的重入次数是否大于了最大值，若是，则抛出异常，否则，设置状态state，返回true，表示成功。
其函数流程图如下：
tryReleaseShared:
tryAcquireShared ：
最后执行到了 fullTryAcquireShared :
这个方法的整体逻辑与 tryAcquireShared 基本相同。
ReadLockReadLock 实现了 Lock 接口，代理调用到逻辑都是 Sync 中 Shared 组的核心方法。ReadLock 可以通过 readLock(): ReadLock 方法获取到。
还有一点值得注意，newCondition() 方法直接抛出了异常，这是因为读锁是一种共享锁，不会导致互斥，所以也就不支持使用 Condition 控制阻塞与唤醒。
WriteLock写锁本质上也是代理 Sync 中的核心方法。
读写锁降级锁降级指的是写锁降级为读锁，如果当前线程拥有写锁，将其释放然后再获取读锁，这种操作过程不是锁降级。锁降级是指把线程当前持有写锁，再去获取读锁，随后释放写锁，这个流程称为锁降级。
锁降级可以保证数据的可见性，如果再持有写锁的情况下，不先去获取读锁，直接释放写锁，再尝试获取读锁，这一系列操作中会有短暂的无锁状态，此时如果有其他线程获取了写锁并修改数据，那么当前线程就无法感知到数据更新，如果当前线程先获取了读锁，那么其他线程就会阻塞，直到当前线程释放读锁后才能获取写锁进行更新。
读写锁 ReentrantReadWriteLock 不支持锁升级，目的是保证数据的可见性，如果读锁已被多个线程获取，其中任意线程成功获取了写锁，并更新了数据，那么这个更新对其他线程是不可见的，容易造成数据不一致问题。
总结 ReentrantReadWriteLock 底层加解锁原理是 AQSReentrantReadWriteLock 分为 ReadLock 和 WriteLock 两种锁，ReadLock 是共享锁，WriteLock 是互斥锁。ReentrantReadWriteLock 的写锁可重入是根据 AQS 中的 state 计数的；读锁的可重入是 Sync 中的 HoldCounter 来记录的。公平策略和非公平策略都需要对读锁和写锁分别实现一个判断逻辑。核心实现在 Sync 方法中。到此这篇关于Java 多线程并发 ReentrantReadWriteLock详情的文章就介绍到这了,更多相关Java ReentrantReadWriteLock内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
