读写锁与邮戳锁

读写锁和邮戳锁

无锁–>独占锁–>读写锁–>邮戳锁

ReentrantReadWriteLock

定义：一个资源能够被多个读线程访问，或者被一个写线程访问，但是不能同时存在读写线程。

读写互斥，读读共享。读没有完成的时候无法获得写锁。

意义和特点

他只允许读读共存，而读写和写写依然是互斥的，大多实际场景是读读线程间并不存在互斥问题。因此引入ReentrantReadWriteLock

一个ReentrantReadWriteLock同时只能存在一个写锁但是可以存在多个读锁，但是不能同时存在写锁和读锁。只有在读多写少的场景之下，读写锁才具有较高的性能体现。

缺点

1. 写锁饥饿问题
2. 锁降级问题

锁降级

就是将写入锁降级为读锁，是为了让当前线程感知到数据的变化，从而保证数据的可见性。

1. 如果同一个线程持有了写锁，在没有释放写锁的情况下，他还是可以继续获得读锁。这就是写锁的降级，降级成了读锁。
2. 规则惯例，先获取写锁，然后获取读锁，在释放写锁的次序。
3. 如果释放了写锁，那么就完全转换为读锁。

但是，从读锁升级到写锁是不可能的。

写锁和读锁是互斥的

这里的互斥，指的是线程间的互斥，当前线程可以获取到写锁又获取到读锁。但是获取到了读锁不能继续获取写锁，这是因为读写锁要保持写操作的可见性。因此，如果允许读锁在被获取的情况下对写锁的获取，那么正在运行的其他读线程无法感知到当前写线程的操作。

ReentrantReadWriteLock在读的过程中，不允许写，只有等待线程都释放了读锁，当前线程才能获得写锁，也就是写入比u等待，这是一种悲观的读锁。

邮戳锁

StampedLock是什么

StampedLock是JDK1.8中新增的一个读写锁，也是对JDK1.5中的读写锁ReentrantReadWriteLock的优化。

邮戳锁 - 也叫票据锁

它是由锁饥饿问题引出

ReentrantReadWriteLock实现了读写分离，但是一旦读操作比较多的时候，想要获取写锁就变得比较困难了，假如当前1000个线程，999个读，1个写，有可能999个读取线程长时间抢到了锁，那1个写线程就悲剧了 因为当前有可能会一直存在读锁，而无法获得写锁，根本没机会写

如何缓解锁饥饿问题？

使用“公平”策略可以一定程度上缓解这个问题：new ReentrantReadWriteLock(true);

但是“公平”策略是以牺牲系统吞吐量为代价的

StampedLock类的乐观读锁闪亮登场

ReentrantReadWriteLock
允许多个线程同时读，但是只允许一个线程写，在线程获取到写锁的时候，其他写操作和读操作都会处于阻塞状态，
读锁和写锁也是互斥的，所以在读的时候是不允许写的，读写锁比传统的synchronized速度要快很多，
原因就是在于ReentrantReadWriteLock支持读并发

StampedLock横空出世
ReentrantReadWriteLock的读锁被占用的时候，其他线程尝试获取写锁的时候会被阻塞。
但是，StampedLock采取乐观获取锁后，其他线程尝试获取写锁时不会被阻塞，这其实是对读锁的优化，
所以，在获取乐观读锁后，还需要对结果进行校验。

StampedLock的特点

• 所有获取锁的方法，都返回一个邮戳（Stamp），Stamp为零表示获取失败，其余都表示成功；
• 所有释放锁的方法，都需要一个邮戳（Stamp），这个Stamp必须是和成功获取锁时得到的Stamp一致；
• StampedLock是不可重入的，危险(如果一个线程已经持有了写锁，再去获取写锁的话就会造成死锁)

StampedLock有三种访问模式

1. Reading（读模式）：功能和ReentrantReadWriteLock的读锁类似
2. Writing（写模式）：功能和ReentrantReadWriteLock的写锁类似
3. Optimistic reading（乐观读模式）：无锁机制，类似于数据库中的乐观锁，支持读写并发，很乐观认为读取时没人修改，假如被修改再实现升级为悲观读模式

StampedLock的缺点

• StampedLock 不支持重入，没有Re开头
• StampedLock 的悲观读锁和写锁都不支持条件变量（Condition），这个也需要注意。
• 使用 StampedLock一定不要调用中断操作，即不要调用interrupt() 方法
  • 如果需要支持中断功能，一定使用可中断的悲观读锁 readLockInterruptibly()和写锁writeLockInterruptibly()