ReadWriteLock 接口详解
ReadWriteLock 接口详解
这是本人阅读ReadWriteLock接口源码的注释后,写出的一篇知识分享博客
读写锁的成分是什么?
- 读锁 Lock readLock();
- 只要没有写锁,读锁可以被多个线程同时拥有
- 写锁 Lock writeLock();
- 写锁是独占的
所有读写锁的实现,都必须保证:写锁的内存同步效果也应该适用于读操作,也就是说,一个获取读锁的线程 应该可以看到上一个写锁所做的所有更新
读写锁与互斥锁的优劣比较
- 相比较于互斥锁,读写锁 在什么情况下 具有更高的性能呢?
- 这取决于数据被读取的频率 ,读和写操作的持续时间,存取数据的冲突
- 也可以说是,同时读写数据的线程的数量
- 例如:一个集合的数据被初始化之后,就很少再修改,然而被频繁的查找,这就是一个读写锁的理想的使用情况。
- 那什么时候不适合用读写锁呢?
- 如果更新数据变得频繁,那么数据大部分时间被独占,使用读写锁 并发性几乎没有增加。
- 此外,如果读操作花费的时间很短,那么读写锁实现 所造成的消耗(读写锁本质上比互斥锁更复杂)会主导执行成本,尤其是
当读写锁的实现 仍然通过一小段代码序列化所有线程时。
- 最终,只有分析和测量才能评价一个读写锁是否适合你的应用程序。
读写锁的实现必须要做的决策
- 在一个写操作释放写锁时,同时有写操作和读操作在等待,确定授予读锁还是写锁。
- 优先写操作较多,因为写操作一般是短的、不频繁的。
- 优先读操作较少,因为如果读操作是频繁的、时间长的,会导致写操作的长时间等待
- 当一个读操作是活跃的,写操作在等待时,一个读操作请求读锁,确定是否授予读锁。
- 优先读操作会无限期的推迟写草所
- 优先写操作会减少并发的可能性
- 确定锁是否可重入
- 一个拥有写锁的线程能否重复获取它?
- 拥有写锁时,能否获取读锁?
- 读锁可以再次获取吗?
- 写锁可以降级为读锁,而不允许插入写操作吗?
- 读锁可以升级为写锁,并优先于其他正在等待的读操作和写操作吗?