多个项目共用同一个redis_浅谈Redis分布式锁(上)

不论面试还是实际工作中，Redis都是避无可避的技术点。在我心里，MySQL和Redis是衡量一个程序员是否“小有所成”的两把标尺。如果他能熟练使用MySQL和Redis，以小化大，充分利用现有资源出色地完成当下需求，说明他已经成长了。

本篇文章我们一起来探讨Redis分布式锁相关的内容。

说到锁，大家第一时间想到的应该是synchronized关键字或ReentrantLock，随即想到偏向锁、自旋锁、重量级锁或者CAS甚至AQS。一般来说，我不喜欢一下子引入这么多概念，可能会把问题弄复杂，但为了方便大家理解Redis分布式锁，这里稍微提一下。

JVM锁

所谓JVM锁，其实指的是诸如synchronized关键字或者ReentrantLock实现的锁。之所以统称为JVM锁，是因为我们的项目其实都是跑在JVM上的。理论上每一个项目启动后，就对应一片JVM内存，后续运行期时数据的生离死别都是在这一片土地上。

什么是锁、怎么锁？

明白了“JVM锁”名字的由来，我们再来聊什么是“锁”，以及怎么“锁”。

有时候我们很难阐述清楚某个事物是什么，但很容易解释它能干什么，JVM锁也是这个道理。JVM锁的出现，就是为了解决线程安全问题。所谓线程安全问题，可以简单地理解为数据不一致（与预期不一致）。

什么时候可能出现线程安全问题呢？

当同时满足以下三个条件时，才可能引发线程安全问题：

• 多线程环境
• 有共享数据
• 有多条语句操作共享数据/单条语句本身非原子操作（比如i++虽然是单条语句，但并非原子操作）

比如线程A、B同时对int count进行+1操作（初始值假设为1），在一定的概率下两次操作最终结果可能为2，而不是3。

那么加锁为什么能解决这个问题呢？

如果不考虑原子性、内存屏障等晦涩的名词，加锁之所以能保证线程安全，核心就是“互斥”。所谓互斥，就是字面意思上的互相排斥。这里的“互相”是指谁呢？就是多线程之间！

怎么实现多线程之间的互斥呢？

引入“中间人”即可。

注意，这是个非常简单且伟大的思想。在编程世界中，通过引入“中介”最终解决问题的案例不胜枚举，包括但不限于Spring、MQ。在码农之间，甚至流传着一句话：没有什么问题是引入中间层解决不了的。

而JVM锁其实就是线程和线程彼此的“中间人”，多个线程在操作加锁数据前都必须去问问“中间人”它是否允许当前线程操作这个数据：

锁在这里扮演的角色其实就是守门员，是唯一的访问入口，所有的线程都要经过它的拷问。在JDK中，锁的实现机制最常见的就是两种，分别是两个派系：

• synchronized关键字
• CAS+AQS

个人觉得s