如果当前的线程A在修改完cache中的数据后，没有获取读锁而是直接释放了写锁；假设此时另一个线程B 获取了写锁并修改了数据，那么线程A无法感知到数据已被修改，但线程A还应用了缓存数据，所以就可能出现数据错误
如果遵循锁降级的步骤，线程A 在释放写锁之前获取读锁，那么线程B在获取写锁时将被阻塞，直到线程A完成数据处理过程，释放读锁，从而保证数据的可见性
那问题又来了：
使用写锁一定要降级吗？
如果你理解了上面的问题，相信这个问题已经有了答案。假如线程A修改完数据之后， 经过耗时操作后想要再使用数据时，希望使用的是自己修改后的数据，而不是其他线程修改后的数据，这样的话确实是需要锁降级；如果只是希望最后使用数据的时候，拿到的是最新的数据，而不一定是自己刚修改过的数据，那么先释放写锁，再获取读锁，然后使用数据也无妨
在这里我要额外说明一下你可能存在的误解：
如果已经释放了读锁再获取写锁不叫锁的升级
如果已经释放了写锁在获取读锁也不叫锁的降级
相信你到这里也理解了锁的升级与降级过程，以及他们被允许或被禁止的原因了
总结本文主要说明了 ReentrantReadWriteLock 是如何应用 state 做位拆分实现读/写两种同步状态的，另外也通过源码分析了读/写锁获取同步状态的过程，最后又了解了读写锁的升级/降级机制，相信到这里你对读写锁已经有了一定的理解。如果你对文中的哪些地方觉得理解有些困难，强烈建议你回看本文开头的两篇文章，那里铺垫了非常多的内容。接下来我们就看看在应用AQS的最后一个并发工具类 CountDownLatch 吧
灵魂追问读锁也没修改数据，还允许共享式获取，那还有必要设置读锁吗？
在分布式环境中，你是如何保证缓存数据一致性的呢？
当你打开看ReentrantReadWriteLock源码时，你会发现，WriteLock 中可以使用 Condition，但是ReadLock 使用Condition却会抛出UnsupportedOperationException，这是为什么呢？
// WriteLock public Condition newCondition() { return sync.newCondition(); } // ReadLock public Condition newCondition() { throw new UnsupportedOperationException(); }个人博客：https://dayarch.top
加我微信好友, 进群娱乐学习交流，备注「进群」
前沿 Java 技术干货分享
高效工具汇总 | 回复「工具」
面试问题分析与解答
技术资料领取 | 回复「资料」
以读侦探小说思维轻松趣味学习 Java 技术栈相关知识，本着将复杂问题简单化，抽象问题具体化和图形化原则逐步分解技术问题，技术持续更新，请持续关注......