jdk1.8的读写锁是在ReentrantReadWriteLock类下实现的。
ReentrantReadWriteLock的构造函数如下，默认也是非公平锁，底层同样用的还是AQS的子类，最先的实现是FairSync和NonfairSync。然后将readerLock和writerLock都实例化出来。
实例化出来的ReadLock也是内部持有了前面实例化出来的sync的实例对象。
当调用lock方法的时候，ReadLock内部仅仅是做了一个原sync实现类里面的方法调用，如下，通过名字可以知道是一个共享锁。
这个类是AQS里实现的，很简单，就是调用tryAcquireShared方法，而tryAcquireShared这个方法是sync抽象类里实现的。
首先拿到当前线程，然后通过调用getState方法拿到当前锁的状态，这个状态是AQS里维护的
然后通过调用exclusiveCount方法通过线程锁当前状态与65535做与运算，与运算只有在两个做与运算的数相同的情况下返回当前数，其他情况下都返回0,。这一步判断结果是如果线程锁对象为65535，且当前锁持有的线程对象与当前线程不是一个线程的话就返回-1，在上一步中会去继续执行doAcquireShared方法
然后通过一个shareCount方法将当前线程状态右移16位算出一个数。这个数代表着重入的次数
readerShouldBlock方法用来判断读锁是否需要被阻塞，判断条件是当前线程锁的阻塞队列不为空，且阻塞队列中的对象不是读锁。且线程的重入次数不能超过65535，最后将线程锁的状态进行一个更新，每次更新会累加65536这样一个数。有人奇怪为什么会是65536呢？首先2的16次方是多少？是65535把，65536比65535多1，前面说过会右移16位，每次加65536然后在计算重入右移16位的时候就能算出线程进来访问的次数了。
如果r为0，则说明是第一次获取锁，然后将当前线程保存给一个firstReader，并且做一个计数统计，如果再次进入还是之前的线程，则对之前的计数进行累加统计。如果不是则进入else执行片段，在sync里面持有一个cachedHoldCounter，从名字可以看到是缓存的一个计数器。先拿到线程的id，然后通过readHolds的get方法进行统计。最后通过HoldCounter的计数器进行累加计数。这里为每一份线程单位维护了一个重入的次数，这个次数是holdCounter对象的count统计的，这个对象内部只有2个数据，一个是线程id，一个是计数。之后的重入都通过修改这个对象的value来进行累计统计
这个方法内部主要是对不同的线程进行缓存，并维护一个不同线程的计数器。
如果之前返回的是-1 则通过调用fullTryAcquireShared方法去循环尝试获取锁。之前满足返回-1 的条件是当前读线程锁累计数量达到65535，且最后一个线程不是锁对象里持有的锁，则返回-1。在fullTryAcquireShared方法里，如果还满足这两个条件则失败，还有一种是读线程获取锁累计达到了65535抛出异常，最后一种情况是线程需要进入阻塞状态，且当前线程既不是第一个获取到锁的线程，同时也之前未获取到过锁，也返回-1.不满足这三种条件的则会一致循环到进入为止。
unlock方法释放锁则是调用的tryReleaseShared方法，如果是第一个获取到锁的线程，先判断次数，如果为1则直接把当前第一个读线程设置为Null,如果不是则对计数减1。
如果是其他线程，同样去获得这个线程的holdCounter对象，如果计数是1或者比1小，直接移除掉这个计数对象，或者对计数做--操作
最后修改状态，每是否一次，通过CAS将状态码减少65536.
这就是读锁源码，真个过程中只有写锁介入的时候才会阻塞。
