Java 读写锁源码分析
前言
在实际项目中，比如我们有一个共享资源文件，我们程序会会同时并发的去读、写这个共享资源文件，那怎么能保证在高并发场景下安全、高效读写呢？ok，看了下文便知
提示：以下是本篇文章正文内容，案例仅供参考
一、技术介绍
1.reentranreadwritelock是什么？
readwritelock提供了readlock和writelock两种锁的操作机制，一个是读锁，一个是写锁，而它的实现类就是reentranreadwritelock
读锁可以在没有写锁的时候被多个线程同时持有，写锁是独占的(排他的)。这意味着每次只能有一个线程写，但可以多个线程并发地读。
理论上，读写锁比互斥锁允许对于共享数据更大程度的并发。与互斥锁相比，读写锁是否能够提高性能取决于读写数据的频率、读取和写入操作的持续时间、以及读线程和写线程之间的竞争。
二、源码分析
1.readlock
直接看readlock源码
可以看到readlock的lock操作实际实现对应sync的 tryacquireshared 方法，我们点进去看看
- 如果另一个线程持有写锁，则失败。
- readershouldblock():读锁是否需要等待（公平锁原则）； r < max_count：持有线程小于最大数 ；compareandsetstate(c, c + shared_unit)：设置读取锁状态；整体意思就是读线程是否应该被阻塞、并且小于最大值、并且比较设置成功
- else判断里读锁数量不为0并且不为当前线程，获取计数器并且+1
- 最后的这行方法执行是由于线程显然不符合条件，或者cas失败或计数饱和，使用完整版本的获取，这里面的方法可处理cas miss 和tryacquireshared中未处理的可重入读
2.writelock
再接着看writelock源码
exclusivecount方法的作用是将同步变量与0xffff做&运算，计算结果就是写锁的数量,因此w的值的含义就是写锁的数量 如果c不为0就表示锁被占用了，占用的是写锁还是读锁呢？这个时候就需要根据w的值来判断了。 如果c等于0就表示此时锁还没有被任何线程占用，那就让线程直接去尝试获取锁.
如果w为0，说明写锁数量为0，而此时又因为c不等于0，说明锁被占用，但是不是写锁，那么此时锁的状态一定是读锁，既然是读锁状态，那么写锁此时来获取锁时，就肯定失败，因此当w等于0时，tryacquire方法返回false。
如果w不为0，说明此时锁的状态时写锁，接着进行current != getexclusiveownerthread()判断，判断持有锁的线程是否是当前线程
如果不是当前线程，那么tryacquire()返回false；如果是当前线程，那么就进行后面的逻辑。为什么是当前线程持有锁，就还能执行后面的逻辑呢？那是因为读写锁是可重入的。
三、单元测试
ok，不废话，接下来上简单直接的单元测试
这里模拟5个读和5个写的并发情况，马上看下执行结果
可以看到多个线程都可以同时获得读锁，而写锁必须等读锁释放了后才能获取，同样的读锁必须等写锁释放了后才能获取
总结
读写锁总结一句话：读读共享、写写互斥、读写互斥。
读写锁的适用场合：相比于 reentrantlock 适用于一般场合，readwritelock 适用读多写少的场景，合理使用可以进一步提高并发
作者寄语
是不是感觉很简单？更多用法请点击下方查看源码,关注我带你揭秘更多高级用法
源码地址：
以上就是java 读写锁源码分析的详细内容，更多关于java 读写锁的资料请关注其它相关文章！