java中的读写锁

引言

---

锁（Lock）是java一个很重要的同步组件，Lock提供了跟synchronized关键字一样的功能，相比synchronized更加灵活，但是实现也更加复杂。

锁的分类：
锁主要分为排他锁和读写锁。

• 排他锁：在同一时刻只允许一个线程进行访问，其他线程等待；
• 读写锁：在同一时刻允许多个读线程访问，但是当写线程访问，所有的写线程和读线程均被阻塞。读写锁维护了一个读锁加一个写锁，通过读写锁分离的模式来保证线程安全，性能高于一般的排他锁。

java并发包提供了读写锁的具体实现ReentrantReadWriteLock，它主要提供了一下特性：

1. 公平性选择：支持公平和非公平（默认）两种获取锁的方式，非公平锁的吞吐量优于公平锁；
2. 可重入：支持可重入，读线程在获取读锁之后能够再次获取读锁，写线程在获取了写锁之后能够再次获取写锁，同时也可以获取读锁；
3. 锁降级：线程获取锁的顺序遵循获取写锁，获取读锁，释放写锁，写锁可以降级成为读锁。

读写锁实现分析

---

读写锁使用案例：缓存

上述代码中，cache使用一个非线程安全的数据结构HashMap作为缓存的实现，并且使用读写锁来保证cache的线程安全。在执行get/set/clear操作都会先获取锁，执行完相应的逻辑后释放锁。

接下来具体分析ReentrantReadWriteLock的具体实现。

成员变量和构造方法

• 读写锁有三个成员变量：读锁，写锁和自定义同步器sync（AQS具体实现）；
• 读写锁提供两个构造方法，默认创建非公平锁。

读写状态

读写锁依赖自定义同步器实现同步功能，读写状态也就是同步器的同步状态。读写锁将整形变量切分成两部分，高16位表示读，低16位表示写：

读写锁通过位运算计算各自的同步状态。假设当前同步状态的值为c，写状态 = c & 0x0000FFFF，读状态 = c >>> 16（无符号补0右移16位）。当写状态增加1，状态变成c+1，当读状态增加1时，状态编程c+(1 <<< 16)，也就是c + 0
x00010000。

注：根据状态的划分可以得出一个推论：当同步状态c不等于0时，如果写状态（c & 0x0000FFFF）等于0，读状态（c >>> 16）大于0，此时，读锁被获取。

写锁的获取与释放

写锁是一个可重入的排他锁，了解AQS的都知道，排他锁的获取的核心实质是AQS tryAcquire的具体实现。

tryAcquire实现

• 计算写状态，写状态 = 当前statue & 0x0000FFFF；
• 同步状态不等于0，表示当前已有线程获取写锁：
  
  • 假如存在读锁（w = 0时表示存在读锁）或者当前线程不是已经获取写锁的线程，返回false，写锁获取失败；
  • 假如w + 当前获取写锁的个数大于写状态最大值（MAX_COUNT = 65531），抛出异常，写锁获取失败；
  • 否则，设置同步状态，设置锁拥有线程为当前线程，锁获取成功；
• 同步状态等于0，表示当前写锁还未被获取，假如当前线程不需要block并且同步状态设置成功，那么，设置锁拥有线程为当前线程，锁获取成功，否则，锁获取失败。
  

  注：为什么存在读锁的时候写锁不能获取？
  读写锁要确保写锁的操作对读锁是可见的，假如允许读锁在已被获取的情况下还能获取写锁，那么正在运行的其他的读线程就无法感知到写线程的操作。所以，只有等待其他的读线程都释放了读锁，写锁才能被当前线程获取，当然，写锁一旦被获取，其他的读写线程的后续访问都会被阻塞。

写锁的释放与ReentrantLock的释放过程基本上是类似的，每次释放都会减少写锁的同步状态，当同步状态等于0的时候，表示该线程写锁已经被释放，其他的读写线程可以继续获取读写锁，并且当前写线程的修改对后续读写线程均可见。写锁的释放核心是自定义同步器的tryRelease实现： **tryRelease实现** 

• 如果待释放写锁的线程不是写锁占有线程，抛出异常；
• 写锁同步状态减少；
• 计算写状态，如果写状态为0，锁释放，设置写锁持有线程为null，设置同步状态，返回；
• 否则，设置同步状态，返回，写锁还未释放。

读锁的获取与释放

读锁是一个可重入的共享锁，它能够同时被多个线程获取，在没有其他写线程访问或者写状态为0时，读锁可以被成功的获取，读状态增加。如果写锁被获取，进入等待状态。接下来我们来看看读锁的核心：自定义同步器的tryAcquireShared实现

tryAcquireShared实现

1. 如果写锁已经被其他写线程获取，获取读锁失败；

2. 计算读状态r（r = c >>> 16），如果当前读线程不需要block，并且r小于读状态最大值，更新读锁同步状态成功：
   a. 读状态 == 0：
   读锁还未被获取，设置第一个拥有读锁的线程firstReader为当前线程，firstReader持有读锁的数量firstReaderHoldCount为1；
   b. 读状态不为0 && firstReader == 当前线程，firstReader持有锁的数量firstReaderHoldCount++；
   c. 不符合a，b条件的，设置读线程的持有读锁数量。

   注：读锁的同步状态是所有线程获取锁的次数的总和，每个读线程获取读锁的次数保存在ThreadLocal中，由线程自己维护。

3. 步骤2失败，循环等待获取读锁。

线程持有读锁数量维护

• readHolds：线程持有读锁数量，底层数据结构是ThreadLocal+HoldCounter，很容易看出来HoldCounter记录线程以及线程获取读锁个数；
  
• cacheHolder：最后一个成功持有读锁的线程的读锁的个数；
• firstReader：第一个成功持有读锁的线程；
• firstReader：firstReader持有读锁的个数。

读锁的每次释放，同写锁的释放一样，也是减少锁的同步状态，核心的实现同样也是自定义同步器的相关共享状态释放tryReleaseShared实现。

tryReleaseShared实现

• 设置线程读锁持有数量；
• 循环释放线程持有的读锁。

读写锁展示内部工作状态实现

• getReadLockCount
  
  返回当前读锁被获取的次数，但是该次数不等于获取读锁的线程数。比如一个线程，连续获取了n次读锁，那么占据读锁的线程数是1，但是，读锁被获取的次数是n，返回n；

• getReadHoldCount
  
  线程获取锁的次数，java 6之后实现更为复杂，线程使用ThreadLocal维护自己获取锁次数；

• isWriteLocked
  
  判断写锁是否被获取，写状态不为0表示锁状态被获取；

• getWriteHoldCount
  
  返回当前写锁被获取的次数。

锁降级

锁降级指的是写锁降级成为读锁，如果当前线程拥有写锁，然后将其释放，最后再获取读锁，这个过程是不能被称为锁降级的。锁降级是指把当前拥有的写锁，再获取到读锁，随后释放写锁的过程。

ReentrantReadWriteLock不支持锁升级（持有读锁，获取写锁，最后释放读锁的过程），目的也是为了数据可见性，如果读锁已经被多个线程获取，其中任意线程成功获取了写锁并且更新了数据，这个更新对其他已经获取到读锁的线程是不可见的。