在多线程环境下，由于上下文的切换，数据可能出现不一致的情况或者数据被污染，我们需要保证数据安全，所以想到了加锁。

所谓的加锁机制呢，就是当一个线程访问该类的某个数据时，进行保护，其他线程不能进行访问，直到该线程读取完，其他线程才可使用。

还记得我之前说过Redis在分布式的情况下，需要对存在并发竞争的数据进行加锁，有人十分费解，Redis是单线程的嘛？为啥还要加锁呢？

你说的不需要加锁的情况是这样的：

 单个服务去访问Redis的时候，确实因为Redis本身单线程的原因是不用考虑线程安全的，但是，现在有哪个公司还是单机的呀？肯定都是分布式集群了嘛。

你看下这样的场景是不是就有问题了：

你们经常不是说秒杀嘛，拿到库存判断，那告诉你分布式情况就是会出问题的。

 我们为了减少DB的压力，把库存预热到了KV，现在KV的库存是1。

1. 服务A去Redis查询到库存发现是1，那说明我能抢到这个商品对不对，那我就准备减一了，但是还没减。

2. 同时服务B也去拿发现也是1，那我也抢到了呀，那我也减。

3. C同理。

4. 等所有的服务都判断完了，你发现诶，怎么变成-2了，超卖了呀，这下完了。

是不是发现问题了，这就需要分布式锁的介入了，我会分三个章节去分别介绍分布式锁的三种实现方式（Zookeeper，Redis，MySQL），说出他们的优缺点，以及一般大厂的实践场景。

正常线程进程同步的机制有哪些？

• 互斥：互斥的机制，保证同一时间只有一个线程可以操作共享资源 synchronized，Lock等。

• 临界值：让多线程串行化去访问资源

• 事件通知：通过事件的通知去保证大家都有序访问共享资源

• 信号量：多个任务同时访问，同时限制数量，比如发令枪CDL，Semaphore等

那分布式锁你了解过有哪些么？

分布式锁实现主要以Zookeeper（以下简称zk）、Redis、MySQL这三种为主。

那先跟我聊一下zk吧，你能说一下他常见的使用场景么？

他主要的应用场景有以下几个：

• 服务注册与订阅（共用节点）

• 分布式通知（监听znode）

• 服务命名（znode特性）

• 数据订阅、发布（watcher）

• 分布式锁（临时节点）

分布式锁之Zookeeper