多个线程同时读一个资源类没有任何问题,所以为了满足并发量,读取共享资源应该可以同时进行
但是,如果有一个线程想去写共享资源来,就不应该在有其他线程可以对该资源进行读或写;
读-读 可以共存,读-写 不能共存, 写-写 可以工作;
写操作:原子+独占,整个过程必须是一个完整的,中间不许被分割,不许被打断;
public interface ReadWriteLockReadWriteLock 维护了一对相关的锁,一个用于只读操作,另一个用于写入操作。只要没有 writer,读取锁可以由多个 reader 线程同时保持。写入锁是独占的。
所有 ReadWriteLock 实现都必须保证 writeLock 操作的内存同步效果也要保持与相关 readLock 的联系。也就是说,成功获取读锁的线程会看到写入锁之前版本所做的所有更新。
与互斥锁相比,读-写锁允许对共享数据进行更高级别的并发访问。虽然一次只有一个线程(writer 线程)可以修改共享数据,但在许多情况下,任何数量的线程可以同时读取共享数据(reader 线程),读-写锁利用了这一点。从理论上讲,与互斥锁相比,使用读-写锁所允许的并发性增强将带来更大的性能提高。在实践中,只有在多处理器上并且只在访问模式适用于共享数据时,才能完全实现并发性增强。
与互斥锁相比,使用读-写锁能否提升性能则取决于读写操作期间读取数据相对于修改数据的频率,以及数据的争用——即在同一时间试图对该数据执行读取或写入操作的线程数。例如,某个最初用数据填充并且之后不经常对其进行修改的 collection,因为经常对其进行搜索(比如搜索某种目录),
所以这样的 collection 是使用读-写锁的理想候选者。
但是,如果数据更新变得频繁&#x