极客时间《Java并发编程实战》笔记---ReadWriteLock与StampedLock

实现缓存的按需加载

package com.codes;

import java.util.Map;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

class Cache<K, V> {
    final Map<K, V> m =
            new HashMap<>();
    final ReadWriteLock rwl =
            new ReentrantReadWriteLock();
    // 读锁
    final Lock r = rwl.readLock();
    // 写锁
    final Lock w = rwl.writeLock();

    // 读缓存
    V get(K key) {
        r.lock();
        try {
            //缓存中存在，直接返回
            if (m.containsKey(key)) {
                return m.get(key);
            }
        } finally {
            r.unlock();
        }

        w.lock(); //⑤
        try {
            //再次检查缓存中是否存在（重点理解！！！）
            if (m.containsKey(key)) {
                return m.get(key);
            }
            //查询数据库并写入
            V value = DB.getByKey(key);
            m.put(key, value);
            return m.get(key);
        } finally {
            w.unlock();
        }
    }
    // 写缓存
    V put(K key, V value) {
        w.lock();
        try {
            return m.put(key, value);
        } finally {
            w.unlock();
        }
    }
}

再次检查缓存是否存在是因为：在高并发的场景下，有可能会有多线程竞争写锁。假设缓存是空的，没有缓存任何东西，如果此时有三个线程 T1、T2 和 T3 同时调用 get() 方法，并且参数 key 也是相同的。那么它们会同时执行到代码⑤处，但**此时只有一个线程能够获得写锁，假设是线程 T1，线程 T1 获取写锁之后查询数据库并更新缓存，最终释放写锁。此时线程 T2 和 T3 会再有一个线程能够获取写锁，假设是 T2，如果不采用再次验证的方式，此时 T2 会再次查询数据库。T2 释放写锁之后，T3 也会再次查询一次数据库。而实际上线程 T1 已经把缓存的值设置好了，T2、T3 完全没有必要再次查询数据库。**所以，再次验证的方式，能够避免高并发场景下重复查询数据的问题。

读写锁的升级与降级

升级就是先获取读锁，然后再升级为写锁，降级就是 先获取写锁，然后再降级为读锁
但是 ReadWriteLock 不支持锁的升级，只支持锁的降级，如果在获取写锁时，没有释放掉占有的读锁就会 导致写锁永久等待，最终导致相关线程都被阻塞，永远也没有机会被唤醒。

原因：由于获取写锁需要释放所有的读锁，在这里是矛盾的。

只有写锁支持条件变量，读锁是不支持条件变量的，读锁调用 newCondition() 会抛出 UnsupportedOperationException 异常。

比读写锁更快的锁—StampedLock

在读多写少的场景下，Java 在 1.8 这个版本里，提供了一种叫 StampedLock 的锁，它的性能比读写锁还要好。

StampedLock 支持的三种锁模式

ReadWriteLock 只支持 读锁和写锁两种模式，但是 StampedLock 提供了三种模式，分别是：写锁、悲观读锁和乐观读。其中，写锁、悲观读锁的语义和 ReadWriteLock 的写锁、读锁的语义完全一样，允许多个线程同时获取悲观读锁，但是只允许一个线程获取写锁，写锁和悲观读锁是互斥的。

不同的是：StampedLock 里的写锁和悲观读锁加锁成功之后，都会返回一个 stamp；然后解锁的时候，需要传入这个 stamp。相关的示例代码如下。

final StampedLock sl = 
  new StampedLock();
  
// 获取/释放悲观读锁示意代码
long stamp = sl.readLock();
try {
  //省略业务相关代码
} finally {
  sl.unlockRead(stamp);
}

// 获取/释放写锁示意代码
long stamp = sl.writeLock();
try {
  //省略业务相关代码
} finally {
  sl.unlockWrite(stamp);
}

那么性能好的主要原因就是：乐观读！特点：无锁操作。并且允许一个线程获取写锁，也就是说不是所有的写操作都被阻塞。

看下面这段示例代码：

class Point {
  private int x, y;
  final StampedLock sl = 
    new StampedLock();
  //计算到原点的距离  
  int distanceFromOrigin() {
    // 乐观读
    long stamp = 
      sl.tryOptimisticRead();
    // 读入局部变量，
    // 读的过程数据可能被修改
    int curX = x, curY = y;
    //判断执行读操作期间，
    //是否存在写操作，如果存在，
    //则sl.validate返回false
    if (!sl.validate(stamp)){
      // 升级为悲观读锁
      stamp = sl.readLock();
      try {
        curX = x;
        curY = y;
      } finally {
        //释放悲观读锁
        sl.unlockRead(stamp);
      }
    }
    return Math.sqrt(
      curX * curX + curY * curY);
  }
}

需要注意的一点是：如果执行乐观读操作的期间，存在写操作，会把乐观读升级为悲观读锁。这个做法挺合理的，否则你就需要在一个循环里反复执行乐观读，直到执行乐观读操作的期间没有写操作（只有这样才能保证 x 和 y 的正确性和一致性），而循环读会浪费大量的 CPU。升级为悲观读锁，代码简练且不易出错，建议你在具体实践时也采用这样的方法。

乐观读的实现与数据库的乐观锁非常相似

极客上讲述了一种很很很容易理解的方式，具体可自行购买查看。

对数据加上一个版本号，查询的时候把 version 字段查出来，更新的时候要利用 version 字段做验证，即可判断是否有人修改过，很妙！

MYSQL 乐观锁及其原理

StampedLock的使用注意事项

• 不支持重入
• StampedLock 的悲观读锁、写锁都不支持条件变量（不能与条件变量一起配合使用）
• 使用 StampedLock 一定不要调用中断操作，如果需要支持中断功能，一定使用可中断的悲观读锁 readLockInterruptibly() 和写锁 writeLockInterruptibly()。否则会导致CPU疯狂飙升。原因：内部实现里while循环里面对中断的处理有点问题

StampedLock 的使用模板，建议在以后的使用中直接套用或参考

StampedLock 读模板：

final StampedLock sl = 
  new StampedLock();
  
// 乐观读
long stamp = 
  sl.tryOptimisticRead();
// 读入方法局部变量
......
// 校验stamp
if (!sl.validate(stamp)){
  // 升级为悲观读锁
  stamp = sl.readLock();
  try {
    // 读入方法局部变量
    .....
  } finally {
    //释放悲观读锁
    sl.unlockRead(stamp);
  }
}
//使用方法局部变量执行业务操作
......

StampedLock 写模板：

long stamp = sl.writeLock();
try {
  // 写共享变量
  ......
} finally {
  sl.unlockWrite(stamp);
}