ReadWriteLock源码分析

ReadWriteLock源码分析

/**
 * Create by ~JH~ on 2018/4/13
 */
/**

 *一个读写锁维持一对锁的联系，一个是只读锁，一个是只写锁，读锁在多线程时是同步的只要没有写操作。
 *写锁是排它锁

 *所有实现了这个接口的类都必须保证写锁内存同步对读锁的影响，
 * 一个成功获取读锁的线程将会看到所有更新的在释放写锁之前

 * 读锁允许高并发的分享数据比起允许互斥锁。他利用一段时间只有一个单例的线程可以修改数据，
 * 在许多情况下，多个线程可以并发的读数据

 *理论上，在并发情况下增加使用读写锁将会导致效率提高相比于使用互斥锁。
 *实际上这种在并发时提高完全发生在多处理器，并且只有接入模式是数据共享时适用。

 * 是否一个读写锁会提高效率相较于互斥锁依赖于这个数据读相比于修改的频率，
 * 读写的持久性，和数据的内容是什么，在同一时间，许多的线程将会尝试读或写。
 * 例如，一个集合初始化的数据在那之后很少修改，但是频繁的查询，使用读写锁是一个理想的候选方式。
 * 然而如果更新变得频繁，数据就会花费较多的时间变成排它锁，如果并发增多的时候，这种情况是很少的。
 * 更进一步，如果读的操作更短花费在读写锁上的成本可以用掉了大部分运行时期的花费，这种实现是比互斥锁更加复杂的
 * 通常作为大多数读写锁的实现仍然是通过所有线程一小段代码连续的。
 * 尽管读写锁的基本操作是简单的，他有一些方案决定一个实现必须要做的，这些可能是读写锁在一个应用的影响
 * 方案如下：
 * 1.当一个写操作释放写锁，读和写都在等待时，决定将锁授予读锁还是写锁。
 * 通常写操作获得锁，因为写的操作短且不频繁。读获得锁的情况较少的，因为，如果读操作频繁且长时间的存活，
 * 他可能导致写操作长时间的延时，公平或者按次序获得，在实现类里面也是可能的。
 * 2.当一个读操作正在进行，写操作正在等待，一个读操作是否能获得读锁，
 * 偏向于读操作可能推迟写操作初始化，然而偏向于写可能减少潜在的并发。
 * 3.决定这个锁是否是可重入锁，是否一个线程可以重复获得，是否在拥有写锁的时候再获得读锁，
 * 这个读锁是否是可重入的。
 * 4.是否一个写锁不通过一个中间的写操作就降级为一个读锁。一个读锁升级为写锁，优先于其他等待的读操作或写操作。

 *你应该考虑这些所有的情况评估在你的应用里面实现的时候是否合适
 * @see ReentrantReadWriteLock
 * @see Lock
 * @see ReentrantLock
 *
 * @since 1.5
 * @author Doug Lea
 */
public interface ReadWriteLock {
    /**
     * Returns the lock used for reading.
     *
     * @return the lock used for reading
     */
    Lock readLock();

    /**
     * Returns the lock used for writing.
     *
     * @return the lock used for writing
     */
    Lock writeLock();
}