image.png

有synchronized实现同步访问为什么还要Lock?

synchronized是通过对象内部的监视器实现，但本质还是依赖底层操作系统的MutexLock实现，是一种重量级锁。而操作系统实现线程间切换需要由用户态切换到核心态时间长成本很高。因此synchronized效率低。

什么是分布式锁？

在分布式系统中，常常需要协调各系统的动作。若不同服务器之间共享一个或一组资源，那么访问时候需要互斥来防止彼此干扰以保证一致性，这时就需要分布式锁。

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。

分布式锁需要具备哪些条件？

互斥性：和本地锁一样互斥性是最基本的，但分布式锁需要保证不同节点的不同线程互斥。
可重入性：同一个节点上的同一个线程如果获得锁后还可以再次获得这个锁。
锁超时：和本地锁一样支持锁超时，以防死锁。
高效，高可用：加锁和解锁需要高效，同时需要保证高可用以防分布式锁失效，可以增加降级。
支持阻塞和非阻塞：和ReentrantLock一样支持lock和tryLock以及tryLock(long timeOut)。
支持公平锁和非公平锁（可选）：公平锁是按照请求加锁的顺序获得锁，非公平锁就是无序的。

实现分布式锁的方式

数据库实现（乐观锁）
为考虑性能一般使用乐观锁
基于Zookeeper的实现

基于redis的实现（推荐）

自研分布式锁：如谷歌的 Chubby

基于redis的实现

基本命令

设置值：SETNX key value
设置过期：expire KEY seconds
删除key： del KEY

三种锁

基本锁：
原理：利用redis的setnx，如果不存在某个key则设置，设置成功表示取得锁成功。
确定：如果获取锁后进程未完就挂了，则永不释放。
改进型：
改进：在基本锁基础上设置超时时间expire，保证超时后也能自动释放。
缺点：setnx与expire不是一个原子操作，可能执行完setnx进程就挂了。
再改进
改进：利用Lua脚本，将setnx与expire 变成一个原子操作，可解决一部分问题。
缺点：还没执行完业务逻辑锁就过期了