极客时间《Java并发编程实战》笔记---ReadWriteLock与StampedLock
文章目录
- 实现缓存的按需加载
- 读写锁的升级与降级
- 比读写锁更快的锁—-StampedLock
- StampedLock 支持的三种锁模式
- 乐观读的实现与数据库的乐观锁非常相似
- StampedLock的使用注意事项
- 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返回falseif (!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();// 读入方法局部变量......// 校验stampif (!sl.validate(stamp)){// 升级为悲观读锁stamp = sl.readLock();try {// 读入方法局部变量.....} finally {//释放悲观读锁sl.unlockRead(stamp);}}//使用方法局部变量执行业务操作......
StampedLock 写模板：
long stamp = sl.writeLock();try {// 写共享变量......} finally {sl.unlockWrite(stamp);}
小咪咪
港控/mmm°
傷城~
小鱼儿
还没有评论，来说两句吧...