「java线程分布式锁」java 分布式锁与并发锁
本篇文章给大家谈谈java线程分布式锁，以及java 分布式锁与并发锁对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
分布式锁及其常见实现方式
在分布式系统中，为了保证对数据的修改有最终一致性，通常使用分布式锁或者分布式事务。比如常见的多个系统同时修改商品，既依赖于现有数据也要修改数据，如果没有限制，高并发情况下很可能最终数据是错误的。
与单机锁不同，分布式锁更加复杂，需要考虑网络延迟、服务阻塞等，通常具有如下特点：
利用数据库主键唯一的特性，可以基于唯一主键保证多次操作只有一次成功。在数据库中创建一个表，表中包含方法名等字段，并在方法名字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入数据，成功插入则获取锁，执行完成后删除对应的行数据释放锁。释放锁时，直接删除数据库记录即可。
此方案存在的问题是强依赖数据库，容易形成热点，数据库锁表导致的超时会影响性能，或者数据库宕机会导致服务不可用。并且，数据库本身没有失效机制，如果任务崩溃会导致数据库中的锁不能被释放。数据库插入操作本身没有阻塞机制，故无法实现分布式锁的阻塞等待，任务线程可能需要重复尝试插入。由于唯一主键的存在，持有锁的线程也无法重复获得锁，其他线程竞争锁的过程中也无法根据优先级进行分配。
在数据库中为表增加一个版本号字段，每次操作时判断版本号，只有版本号一致才能进行对应的修改，修改后版本号加 1，通过 CAS 的方式进行修改。
此实现会增加数据库操作的次数，高并发情况下可能性能不好。
for update是一种行级锁，又叫排它锁，一旦用户对某个行施加了行级加锁，则该用户可以查询也可以更新被加锁的数据行，其它用户只能查询但不能更新被加锁的数据行。我们可以认为获得排他锁的线程即获得分布式锁，任务执行完成后通过 commit 来释放锁。for update 语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。
但是 MySQL 会对查询进行优化，即便在条件中使用了索引字段，但是否使用索引来检索数据是由 MySQL 通过判断不同执行计划的代价来决定的，如果 MySQL 认为全表扫效率更高，比如对一些很小的表，它就不会使用索引，这种情况下 InnoDB 将使用表锁，而不是行锁。
setnx 的含义就是 SET if Not Exists，主要有两个参数 setnx(key, value)。该方法是原子的，如果 key 不存在，则设置当前 key 成功，返回 1；如果当前 key 已经存在，则设置当前 key 失败，返回 0。setnx 命令不能设置 key 的超时时间，只能通过 expire() 来设置。
锁的实现步骤：
这个方案如果在第一步 setnx 执行成功后，在 expire() 命令执行成功前，发生了宕机的现象，那么就依然会出现死锁的问题。
这个方案是对上一个方案的优化版本。
getset() 命令主要有两个参数 getset(key，newValue)。该方法是原子的，对 key 设置 newValue 这个值，并且返回 key 原来的旧值。假设 key 原来是不存在的，那么首次执行的返回值是 null。
锁的实现步骤：
这个方案在任务处理超时或发生宕机时，无需担心锁超时问题，下次请求可以判断出实际上锁已经超时了。
zookeeper 由多个节点构成（单数），采用 zab 一致性协议。因此可以将 zk 看成一个单点结构，对其修改数据其内部自动将所有节点数据进行修改而后才提供查询服务。
zookeeper 数据是目录树的形式，每个目录称为 znode， znode 中可存储数据（一般不超过 1M），还可以在其中增加子节点。
子节点有三种类型。
zookeeper 提供了 Watch 机制，client 可以监控每个节点的变化，当产生变化会给 client 产生一个事件。
可以利用临时节点与 watch 机制实现分布式锁。每个锁占用一个普通节点 /lock，当需要获取锁时在 /lock 目录下创建一个临时节点，创建成功则表示获取锁成功，失败则 watch/lock 节点，有删除操作后再去争锁。临时节点好处在于当进程挂掉后锁的节点自动删除不会发生死锁。
缺点在于所有取锁失败的进程都监听父节点，很容易发生羊群效应，即当释放锁后所有等待进程一起来创建节点，并发量很大。
一个可行的优化方案是上锁改为创建临时有序节点，每个上锁的节点均能创建节点成功，只是其序号不同。只有序号最小的可以拥有锁，如果这个节点序号不是最小的则 watch 序号比本身小的前一个节点 (公平锁)。watch 事件到来后，再次判断是否序号最小。取锁成功则执行代码，最后释放锁（删除该节点）。
性能上可能没有缓存服务那么高，因为每次在创建锁和释放锁的过程中，都要动态创建、销毁临时节点来实现锁功能。zookeeper 中创建和删除节点只能通过 Leader 服务器来执行，然后将数据同步到所有的 Follower 机器上。
分布式锁比较复杂，也比较容易发生死锁。目前主流的实现方式包括：
分布式锁及其常见实现方式 - 程序之心
分布式锁
与分布式锁对应的是【单机锁】，我们在写多线程程序时，避免同时操作一个共享变量而产生数据问题，通常会使用一把锁来实现【互斥】，其使用范围是在【同一个进程中】。（同一个进程内存是共享的，以争抢同一段内存，来判断是否抢到锁）。
如果是多个进程，如何互斥呢。就要引入【分布式锁】来解决这个问题。想要实现分布式锁，必须借助一个外部系统，所有进程都去这个系统上去【申请加锁】。
而这个外部系统，必须要实现【互斥】的能力，即两个请求同时进来，只会给一个进程返回成功，另一个返回失败（或等待）。
这个外部系统，可以是 MySQL，也可以是 Redis 或 Zookeeper。但为了追求更好的性能，我们通常会选择使用 Redis 或 Zookeeper 来做。
依赖mysql的行锁 select for update。
一个特例，唯一索引。唯一索引是找到了就直接停止遍历，非唯一索引还会向后遍历一行。移步第八个case。
现在的索引：
分析：
单条命中只会加行锁，不加间隙锁。所以RC/RR是一样的。
事务1对id=10这条记录加行锁。所以 场景1会锁等待，场景2不会锁等待 。
分析：
RC隔离级别：
事务1未命中，不会加任何锁。所以 场景1，场景2，场景3都不会锁等待 。
RR隔离级别：
事务1未命中，会加间隙锁。因为主键查询，只会对主键加锁。
在10和18加间隙锁。
间隙锁和查询不冲突。 场景1不会锁等待 。
间隙锁和插入冲突。 场景2和场景3会锁等待 。
分析
单条命中只会加行锁，不加间隙锁。所以RC/RR是一样的。
事务1对二级索引和主键索引加行锁。 事务1和事务2都会发生锁等待 。
分析
RC隔离级别：
事务1未命中，不会加任何锁。所以 场景1，场景2，场景3都不会锁等待 。
RR隔离级别：
事务1对二级索引N0007到正无穷上间隙锁，主键索引不上锁。 场景1会锁等待，场景2不会锁等待 。
分析：
RC隔离级别：
只会加行锁。 场景1场景2会锁等待 。 场景3不会发生锁等待 。
RR隔离级别：
会加行锁和间隙锁。 场景1场景2场景3都会锁等待 。
ps: 如果是唯一索引，只会加行锁。非唯一才会加间隙锁。
RC隔离级别：
事务1未命中，不会加任何锁。所以 场景1，场景2都不会锁等待 。
RR隔离级别：
事务1未命中，会加间隙锁。间隙锁与查询不冲突， 场景1不会发生锁等待 。 场景2会发生锁等待 。
分析
RC隔离级别：
事务1加了三个行锁。 场景1会锁等待。场景2，场景3不会发生锁等待 。
RR隔离级别：
事务1加个三个行锁和间隙锁。 场景1，场景3会发生锁等待 。间隙锁与查询不冲突， 场景2不会锁等待。
分析：
RC隔离级别：
事务1加的都是行锁。 场景1会发生锁等待 ， 场景2，场景3不会发生锁等待 。
RR隔离级别：
事务1会对二级索引加行锁和间隙锁，对主键索引加行锁。
场景1，场景3会发生锁等待 。间隙锁与查询不冲突， 场景2不会锁等待。
这么看，二级索引和唯一索引没什么区别。
那如果是 select * from book where name 'Jim' for update; 呢
如果name是唯一索引。因为找到jim就不会向后遍历了，所以jim和rose之间不会有间隙锁。
分析：
RC隔离级别：
由于没有走索引，所以只能全表扫描。在命中的主键索引上加行锁。 场景1会锁等待，场景2不会锁等待 。
RR隔离级别：
不开启innodb_locks_unsafe_for_binlog。 会发生锁表 。
开启innodb_locks_unsafe_for_binlog。和RC隔离级别一样。
RC隔离级别：
未命中不加锁。 场景1，场景2都不会锁等待 。
RR隔离级别：
未命中， 锁表 。
在RR隔离级别下，where条件没有索引，都会锁表。
加锁命令：
释放锁命令：
这里存在问题，当释放锁之前异常退出了。这个锁就永远不会被释放了。
怎么解决呢？加一个超时时间。
还有问题，不是原子操作。
redis 2.6.12之后，redis天然支持了
来看一下还有什么问题：
试想这样一个场景
看到了么，这里存在两个严重的问题：
释放别人的锁 ：客户端 1 操作共享资源完成后，却又释放了客户端 2 的锁
锁过期 ：客户端 1 操作共享资源耗时太久，导致锁被自动释放，之后被客户端 2 持有
解决办法是：客户端在加锁时，设置一个只有自己知道的【唯一标识】进去。
例如，可以是自己的线程id，也可以是一个uuid
在释放锁时，可以这么写：
问题来了，还不是原子的。redis没有原生命令了。这里需要使用lua脚本
锁的过期时间如果评估不好，这个锁就会有「提前」过期的风险，一般的妥协方案是，尽量「冗余」过期时间，降低锁提前过期的概率。
其实可以有比较好的方案：
加锁时，先设置一个过期时间，然后我们开启一个「守护****线程****」，定时去检测这个锁的失效时间，如果锁快要过期了，操作共享资源还未完成，那么就自动对锁进行「续期」，重新设置过期时间。
这个守护线程我们一般把他叫做【看门狗】线程。
我们在使用 Redis 时，一般会采用 主从集群 + 哨兵 的模式部署，这样做的好处在于，当主库异常宕机时，哨兵可以实现「故障自动切换」，把从库提升为主库，继续提供服务，以此保证可用性。
试想这样的场景：
为此，Redis 的作者提出一种解决方案，就是我们经常听到的 Redlock（红锁） 。
现在我们来看，Redis 作者提出的 Redlock 方案，是如何解决主从切换后，锁失效问题的。
Redlock 的方案基于 2 个前提：
也就是说，想用使用 Redlock，你至少要部署 5 个 Redis 实例，而且都是主库，它们之间没有任何关系，都是一个个孤立的实例。
Redlock 具体如何使用呢？
整体的流程是这样的，一共分为 5 步：
有 4 个重点：
1) 为什么要在多个实例上加锁？
本质上是为了「容错」，部分实例异常宕机，剩余的实例加锁成功，整个锁服务依旧可用。
2) 为什么大多数加锁成功，才算成功？
多个 Redis 实例一起来用，其实就组成了一个「分布式系统」。
在分布式系统中，总会出现「异常节点」，所以，在谈论分布式系统问题时，需要考虑异常节点达到多少个，也依旧不会影响整个系统的「正确性」。
这是一个分布式系统「容错」问题，这个问题的结论是： 如果只存在「故障」节点，只要大多数节点正常，那么整个系统依旧是可以提供正确服务的。
3) 为什么步骤 3 加锁成功后，还要计算加锁的累计耗时？
因为操作的是多个节点，所以耗时肯定会比操作单个实例耗时更久，而且，因为是网络请求，网络情况是复杂的，有可能存在 延迟、丢包、超时 等情况发生，网络请求越多，异常发生的概率就越大。
所以，即使大多数节点加锁成功，但如果加锁的累计耗时已经「超过」了锁的过期时间，那此时有些实例上的锁可能已经失效了，这个锁就没有意义了。
4) 为什么释放锁，要操作所有节点？
在某一个 Redis 节点加锁时，可能因为「网络原因」导致加锁失败。
例如，客户端在一个 Redis 实例上加锁成功，但在读取响应结果时，网络问题导致 读取失败 ，那这把锁其实已经在 Redis 上加锁成功了。
所以，释放锁时，不管之前有没有加锁成功，需要释放「所有节点」的锁，以保证清理节点上「残留」的锁。
好了，明白了 Redlock 的流程和相关问题，看似 Redlock 确实解决了 Redis 节点异常宕机锁失效的问题，保证了锁的「安全性」。
在martin的文章中，主要阐述了4个论点：
第一：效率 。
使用分布式锁的互斥能力，是避免不必要地做同样的工作两次。如果锁失效，并不会带来「恶性」的后果，例如发了 2 次邮件等，无伤大雅。
第二：正确性 。
使用锁用来防止并发进程相互干扰。如果锁失败，会造成多个进程同时操作同一条数据，产生的后果是数据严重错误、永久性不一致、数据丢失等恶性问题，后果严重。
他认为，如果你是为了前者——效率，那么使用单机版redis就可以了，即使偶尔发生锁失效（宕机、主从切换），都不会产生严重的后果。而使用redlock太重了，没必要。
而如果是为了正确性，他认为redlock根本达不到安全性的要求，也依旧存在锁失效的问题！
一个分布式系统，存在着你想不到的各种异常。这些异常场景主要包括三大块，这也是分布式系统会遇到的三座大山： NPC
martin用一个进程暂停（GC）的例子，指出了redlock安全性的问题：
又或者，当多个Redis节点时钟发生了问题时，也会导致redlock锁失效。
在混乱的分布式系统中，你不能假设系统时钟就是对的。
个人理解，相当于在业务层再做一层乐观锁。
一个好的分布式锁，无论 NPC 怎么发生，可以不在规定时间内给出结果，但并不会给出一个错误的结果。也就是只会影响到锁的「性能」（或称之为活性），而不会影响它的「正确性」。
1、Redlock 不伦不类 ：它对于效率来讲，Redlock 比较重，没必要这么做，而对于正确性来说，Redlock 是不够安全的。
2、时钟假设不合理 ：该算法对系统时钟做出了危险的假设（假设多个节点机器时钟都是一致的），如果不满足这些假设，锁就会失效。
3、无法保证正确性 ：Redlock 不能提供类似 fencing token 的方案，所以解决不了正确性的问题。为了正确性，请使用有「共识系统」的软件，例如 Zookeeper。
好了，以上就是 Martin 反对使用 Redlock 的观点，看起来有理有据。
下面我们来看 Redis 作者 Antirez 是如何反驳的。
首先，Redis 作者一眼就看穿了对方提出的最为核心的问题： 时钟问题 。
Redis 作者表示，Redlock 并不需要完全一致的时钟，只需要大体一致就可以了，允许有「误差」。
例如要计时 5s，但实际可能记了 4.5s，之后又记了 5.5s，有一定误差，但只要不超过「误差范围」锁失效时间即可，这种对于时钟的精度的要求并不是很高，而且这也符合现实环境。
对于对方提到的「时钟修改」问题，Redis 作者反驳到：
Redis 作者继续论述，如果对方认为，发生网络延迟、进程 GC 是在客户端确认拿到了锁，去操作共享资源的途中发生了问题，导致锁失效，那这 不止是 Redlock 的问题，任何其它锁服务例如 Zookeeper，都有类似的问题，这不在讨论范畴内 。
这里我举个例子解释一下这个问题：
Redis 作者这里的结论就是：
所以，Redis 作者认为 Redlock 在保证时钟正确的基础上，是可以保证正确性的。
这个方案必须要求要操作的「共享资源服务器」有拒绝「旧 token」的能力。
例如，要操作 MySQL，从锁服务拿到一个递增数字的 token，然后客户端要带着这个 token 去改 MySQL 的某一行，这就需要利用 MySQL 的「事物隔离性」来做。
但如果操作的不是 MySQL 呢？例如向磁盘上写一个文件，或发起一个 HTTP 请求，那这个方案就无能为力了，这对要操作的资源服务器，提出了更高的要求。
也就是说，大部分要操作的资源服务器，都是没有这种互斥能力的。
再者，既然资源服务器都有了「互斥」能力，那还要分布式锁干什么？
利用 zookeeper 的同级节点的唯一性特性，在需要获取排他锁时，所有的客户端试图通过调用 create() 接口，在 /exclusive_lock 节点下创建临时子节点 /exclusive_lock/lock ，最终只有一个客户端能创建成功，那么此客户端就获得了分布式锁。同时，所有没有获取到锁的客户端可以在 /exclusive_lock 节点上注册一个子节点变更的 watcher 监听事件，以便重新争取获得锁。
锁释放依赖心跳。集群中占用锁的客户端失联时，锁能够被有效释放。一旦占用Znode锁的客户端与ZooKeeper集群服务器失去联系，这个临时Znode也将自动删除
zookeeper的高可用依赖zab。简单的说就是写入时，半数follower ack，写入成功。
zk是100%安全的么：
分析一个例子：
所以，得出一个结论： 一个分布式锁，在极端情况下，不一定是安全的。
redlock运维成本也比较高。单机有高可用问题。所以还是主从+哨兵这样的部署方式会好一些。
redis的缺点是：不是100%可靠。
mysql的缺点是：扛不住高流量请求。
可以二者结合，先用redis做分布式锁，扛住大部分流量缓解mysql压力。最后一定要用mysql做兜底保证100%的正确性。
多服务器java毫秒内的重复请求怎么处理？
你好，很高兴回答你的问题。
这种问题，有相对成熟的机制来解决。这种机制叫分布式锁。
其实和单机部署时的同步锁类似，单机部署是一个线程获取到锁之后，另一个线程因为获取不到锁就不能和上一个线程同时执行。
分布式锁道理类似，这个锁一般会由一个独立于部署的多个服务实例之外的系统来解决。比如redis，redis有个方法是setNx(key)这个方法是原子性的，如果redis中不存在key对应的数据，则会存入，相当于获取到锁，如果redis中已经存在key对应的数据，说明锁已经被占用，就会返回false。
放服务实例处理完这个业务功能后可以删除掉redis中的数据，相当于适当锁。
为了防止因意外情况导致不会执行释放锁的操作，可以给存入redis的数据设置一个过期时间，如果时间到了，数据还没有被删除，redis会自行删除这条数据。
如果有帮助到你，请点击采纳。
使用Redisson实现分布式锁
Redisson的分布式可重入锁RLock Java对象实现了java.util.concurrent.locks.Lock接口，同时还支持自动过期解锁。
Redisson同时还为分布式锁提供了异步执行的相关方法：
Redisson分布式可重入公平锁也是实现了java.util.concurrent.locks.Lock接口的一种RLock对象。在提供了自动过期解锁功能的同时，保证了当多个Redisson客户端线程同时请求加锁时，优先分配给先发出请求的线程。
Redisson同时还为分布式可重入公平锁提供了异步执行的相关方法：
Redisson的RedissonMultiLock对象可以将多个RLock对象关联为一个联锁，每个RLock对象实例可以来自于不同的Redisson实例。
Redisson的RedissonRedLock对象实现了 Redlock 介绍的加锁算法。该对象也可以用来将多个RLock
对象关联为一个红锁，每个RLock对象实例可以来自于不同的Redisson实例。
Redisson的分布式可重入读写锁RReadWriteLock Java对象实现了java.util.concurrent.locks.ReadWriteLock接口。同时还支持自动过期解锁。该对象允许同时有多个读取锁，但是最多只能有一个写入锁。
Redisson的分布式信号量（Semaphore）Java对象RSemaphore采用了与java.util.concurrent.Semaphore相似的接口和用法。
Redisson的可过期性信号量（PermitExpirableSemaphore）实在RSemaphore对象的基础上，为每个信号增加了一个过期时间。每个信号可以通过独立的ID来辨识，释放时只能通过提交这个ID才能释放。
Redisson的分布式闭锁（CountDownLatch）Java对象RCountDownLatch采用了与java.util.concurrent.CountDownLatch相似的接口和用法。
Redisson 分布式锁和同步器
分布式锁的三种实现方式
分布式锁的三种实现方式分别是：基于数据库实现分布式锁、基于缓存（Redis等）实现分布式锁、基于Zookeeper实现分布式锁。
一、基于数据库实现分布式锁
1、悲观锁
利用select … where … for update 排他锁。
注意：其他附加功能与实现一基本一致，这里需要注意的是“where name=lock ”，name字段必须要走索引，否则会锁表。有些情况下，比如表不大，mysql优化器会不走这个索引，导致锁表问题。
2、乐观锁
所谓乐观锁与前边最大区别在于基于CAS思想，是不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能觉察到，抢购和秒杀就是用了这种实现以防止超卖，通过增加递增的版本号字段实现乐观锁。
二、基于缓存（Redis等）实现分布式锁
1、使用命令介绍：
（1）SETNX
SETNX key val：当且仅当key不存在时，set一个key为val的字符串，返回1；若key存在，则什么都不做，返回0。
（2）expire
expire key timeout：为key设置一个超时时间，单位为second，超过这个时间锁会自动释放，避免死锁。
（3）delete
delete key：删除key
在使用Redis实现分布式锁的时候，主要就会使用到这三个命令。
2、实现思想：
（1）获取锁的时候，使用setnx加锁，并使用expire命令为锁添加一个超时时间，超过该时间则自动释放锁，锁的value值为一个随机生成的UUID，通过此在释放锁的时候进行判断。
（2）获取锁的时候还设置一个获取的超时时间，若超过这个时间则放弃获取锁。
（3）释放锁的时候，通过UUID判断是不是该锁，若是该锁，则执行delete进行锁释放。
三、基于Zookeeper实现分布式锁
ZooKeeper是一个为分布式应用提供一致性服务的开源组件，它内部是一个分层的文件系统目录树结构，规定同一个目录下只能有一个唯一文件名。
基于ZooKeeper实现分布式锁的步骤如下：
（1）创建一个目录mylock。
（2）线程A想获取锁就在mylock目录下创建临时顺序节点。
（3）获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁。
（4）线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点。
（5）线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。
扩展资料；
一、数据库分布式锁实现的缺点：
1、db操作性能较差，并且有锁表的风险。
2、非阻塞操作失败后，需要轮询，占用cpu资源。
3、长时间不commit或者长时间轮询，可能会占用较多连接资源。
二、Redis(缓存)分布式锁实现的缺点：
1、锁删除失败，过期时间不好控制。
2、非阻塞，操作失败后，需要轮询，占用cpu资源。
三、ZK分布式锁实现的缺点：
性能不如redis实现，主要原因是写操作（获取锁释放锁）都需要在Leader上执行，然后同步到follower。
高并发没锁可不行，三种分布式锁详解
Java中的锁主要包括synchronized锁和JUC包中的锁，这些锁都是针对单个JVM实例上的锁，对于分布式环境如果我们需要加锁就显得无能为力。在单个JVM实例上，锁的竞争者通常是一些不同的线程，而在分布式环境中，锁的竞争者通常是一些不同的线程或者进程。如何实现在分布式环境中对一个对象进行加锁呢？答案就是分布式锁。
目前分布式锁的实现方案主要包括三种：
基于数据库实现分布式锁主要是利用数据库的唯一索引来实现，唯一索引天然具有排他性，这刚好符合我们对锁的要求：同一时刻只能允许一个竞争者获取锁。加锁时我们在数据库中插入一条锁记录，利用业务id进行防重。当第一个竞争者加锁成功后，第二个竞争者再来加锁就会抛出唯一索引冲突，如果抛出这个异常，我们就判定当前竞争者加锁失败。防重业务id需要我们自己来定义，例如我们的锁对象是一个方法，则我们的业务防重id就是这个方法的名字，如果锁定的对象是一个类，则业务防重id就是这个类名。
基于缓存实现分布式锁：理论上来说使用缓存来实现分布式锁的效率最高，加锁速度最快，因为Redis几乎都是纯内存操作，而基于数据库的方案和基于Zookeeper的方案都会涉及到磁盘文件IO，效率相对低下。一般使用Redis来实现分布式锁都是利用Redis的 SETNX key value 这个命令，只有当key不存在时才会执行成功，如果key已经存在则命令执行失败。
基于Zookeeper：Zookeeper一般用作配置中心，其实现分布式锁的原理和Redis类似，我们在Zookeeper中创建瞬时节点，利用节点不能重复创建的特性来保证排他性。
在实现分布式锁的时候我们需要考虑一些问题，例如：分布式锁是否可重入，分布式锁的释放时机，分布式锁服务端是否有单点问题等。
上面已经分析了基于数据库实现分布式锁的基本原理：通过唯一索引保持排他性，加锁时插入一条记录，解锁是删除这条记录。下面我们就简要实现一下基于数据库的分布式锁。
id字段是数据库的自增id，unique_mutex字段就是我们的防重id，也就是加锁的对象，此对象唯一。在这张表上我们加了一个唯一索引，保证unique_mutex唯一性。holder_id代表竞争到锁的持有者id。
如果当前sql执行成功代表加锁成功，如果抛出唯一索引异常(DuplicatedKeyException)则代表加锁失败，当前锁已经被其他竞争者获取。
解锁很简单，直接删除此条记录即可。
是否可重入 ：就以上的方案来说，我们实现的分布式锁是不可重入的，即是是同一个竞争者，在获取锁后未释放锁之前再来加锁，一样会加锁失败，因此是不可重入的。解决不可重入问题也很简单：加锁时判断记录中是否存在unique_mutex的记录，如果存在且holder_id和当前竞争者id相同，则加锁成功。这样就可以解决不可重入问题。
锁释放时机 ：设想如果一个竞争者获取锁时候，进程挂了，此时distributed_lock表中的这条记录就会一直存在，其他竞争者无法加锁。为了解决这个问题，每次加锁之前我们先判断已经存在的记录的创建时间和当前系统时间之间的差是否已经超过超时时间，如果已经超过则先删除这条记录，再插入新的记录。另外在解锁时，必须是锁的持有者来解锁，其他竞争者无法解锁。这点可以通过holder_id字段来判定。
数据库单点问题 ：单个数据库容易产生单点问题：如果数据库挂了，我们的锁服务就挂了。对于这个问题，可以考虑实现数据库的高可用方案，例如MySQL的MHA高可用解决方案。
使用Jedis来和Redis通信。
可以看到，我们加锁就一行代码：
jedis.set(String key, String value, String nxxx, String expx, int time);
这个set()方法一共五个形参：
第一个为key,我们使用key来当锁，因为key是唯一的。
第二个为value，这里写的是锁竞争者的id，在解锁时，我们需要判断当前解锁的竞争者id是否为锁持有者。
第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作。
第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期时间的设置，具体时间由第五个参数决定；
第五个参数为time，与第四个参数相呼应，代表key的过期时间。
总的来说，执行上面的set()方法就只会导致两种结果：1.当前没有锁（key不存在）,那么久进行加锁操作，并对锁设置一个有效期，同时value表示加锁的客户端。2.已经有锁存在，不做任何操作。
上述解锁请求中， SET_IF_NOT_EXIST (不存在则执行)保证了加锁请求的排他性，缓存超时机制保证了即使一个竞争者加锁之后挂了，也不会产生死锁问题：超时之后其他竞争者依然可以获取锁。通过设置value为竞争者的id，保证了只有锁的持有者才能来解锁，否则任何竞争者都能解锁，那岂不是乱套了。
解锁的步骤：
注意到这里解锁其实是分为2个步骤，涉及到解锁操作的一个原子性操作问题。这也是为什么我们解锁的时候用Lua脚本来实现，因为Lua脚本可以保证操作的原子性。那么这里为什么需要保证这两个步骤的操作是原子操作呢？
设想：假设当前锁的持有者是竞争者1，竞争者1来解锁，成功执行第1步，判断自己就是锁持有者，这是还未执行第2步。这是锁过期了，然后竞争者2对这个key进行了加锁。加锁完成后，竞争者1又来执行第2步，此时错误产生了：竞争者1解锁了不属于自己持有的锁。可能会有人问为什么竞争者1执行完第1步之后突然停止了呢？这个问题其实很好回答，例如竞争者1所在的JVM发生了GC停顿，导致竞争者1的线程停顿。这样的情况发生的概率很低，但是请记住即使只有万分之一的概率，在线上环境中完全可能发生。因此必须保证这两个步骤的操作是原子操作。
是否可重入 ：以上实现的锁是不可重入的，如果需要实现可重入，在 SET_IF_NOT_EXIST 之后，再判断key对应的value是否为当前竞争者id，如果是返回加锁成功，否则失败。
锁释放时机 ：加锁时我们设置了key的超时，当超时后，如果还未解锁，则自动删除key达到解锁的目的。如果一个竞争者获取锁之后挂了，我们的锁服务最多也就在超时时间的这段时间之内不可用。
Redis单点问题 ：如果需要保证锁服务的高可用，可以对Redis做高可用方案：Redis集群+主从切换。目前都有比较成熟的解决方案。
利用Zookeeper创建临时有序节点来实现分布式锁：
其基本思想类似于AQS中的等待队列，将请求排队处理。其流程图如下：
解决不可重入 ：客户端加锁时将主机和线程信息写入锁中，下一次再来加锁时直接和序列最小的节点对比，如果相同，则加锁成功，锁重入。
锁释放时机 ：由于我们创建的节点是顺序临时节点，当客户端获取锁成功之后突然session会话断开，ZK会自动删除这个临时节点。
单点问题 ：ZK是集群部署的，主要一半以上的机器存活，就可以保证服务可用性。
Zookeeper第三方客户端curator中已经实现了基于Zookeeper的分布式锁。利用curator加锁和解锁的代码如下：
java线程分布式锁的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java 分布式锁与并发锁、java线程分布式锁的信息别忘了在本站进行查找喔。
发布于：2022-12-25，除非注明，否则均为原创文章，转载请注明出处。