前言Curator 同样支持分布式读写锁 和联锁，只需要使用 InterProcessReadWriteLock 即可，来一起看看它的源码以及实现方式。 使用方式public class CuratorDemo { public static void main(String[] args) throws Exception { String connectString = "127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183"; RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3); CuratorFramework client = CuratorFrameworkFactory .builder() .connectString(connectString) .retryPo ...

前言分布式信号量，之前在 Redisson 中也介绍过，Redisson 的信号量是将计数维护在 Redis 中的，那现在来看一下 Curator 是如何基于 ZooKeeper 实现信号量的。 使用 Demopublic class CuratorDemo { public static void main(String[] args) throws Exception { String connectString = "127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183"; RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3); CuratorFramework client = CuratorFrameworkFactory .builder() .connectString(connectString) ...

前言在了解了加锁和锁重入之后，最需要了解的还是在分布式场景下或者多线程并发加锁是如何处理的？ 并发加锁 先来看结果，在多线程对 /locks/lock_01 加锁时，是在后面又创建了新的临时节点。 这块在加锁方法 CreateBuilderImpl#pathInForeground 中已经介绍过 这里判断 /locks/lock_01 路径已经存在，会直接创建新的临时顺序节点。 真正判断锁是否获取成功，其实是在 LockInternals#attemptLock 方法中的 internalLockLoop 方法中。 加锁结果及监听internalLockLoop 方法的主要作用是判断加锁结果，以及获取锁失败时，对其他节点的监听。 获取父节点 /locks/lock_01 下的所有子节点，按照从小到大排序，判断自己是不是获取到锁，没有获取到就监听自己前一个节点； 支持设置超时时间，超时直接返回失败； 不支持设置超时时间或者还没有超时，则直接 wait 等待。 是否获取锁的代码在 StandardLockInternalsDriver#getsTheLock 这块就是判断是否为 ...

前言加锁逻辑已经介绍完毕，那当一个线程重复加锁是如何处理的呢？ 锁重入在上一小节中，可以看到加锁的过程，再回头看 internalLock 这个方法。 加锁成功之后，将当前线程放到 threadData 中，threadData 是 ConcurrentMap<Thread, LockData> 类型的，不用担心并发问题。 假如锁重入了，直接就会在上一部分 lockData != null 被拦下，然后执行 lockData.lockCount.incrementAndGet();。 对 lockCount 自增，代表了锁重入。 这里发现了吧！Curator 的锁重入是在 Java 代码中实现的。 锁释放当锁需要释放的时候，只需要调用 lock.release() 进行释放即可，具体是如何释放的呢？ 主要分为两部分： 递减 threadData 中当前线程的加锁次数； 加锁次数大于 0，说明还剩余重入次数，直接返回； 加锁次数等于 0，则 releaseLock 释放锁，并删除 threadData 中当前线程 key。 releaseLock 方法中就没有多少复杂 ...

前言一般工作中常用的分布式锁，就是基于 Redis 和 ZooKeeper，前面已经介绍完了 Redisson 锁相关的源码，下面一起看看基于 ZooKeeper 的锁。也就是 Curator 这个框架。 Curator 的锁也分为很多种，本文分析共享可重入锁。 考虑到如果文章篇幅较长，不太适合阅读，所以对文章做了适当的拆分。 环境配置 本机三个节点 版本：3.7.0系统：macOS安装方式：brew install zookeeperCurator Maven 依赖版本：5.1.0 <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>5.1.0</version> </dependency> 加锁示例 详细信息可参考官方文档。 加锁前 在加锁之前，ZooKeeper 仅有一个节点 /zookeeper。 加锁中在 ...

前言Redisson 除了提供了分布式锁之外，还额外提供了同步组件，Semaphore 和 CountDownLatch。 Semaphore 意思就是在分布式场景下，只有 3 个凭证，也就意味着同时只会有三个线程执行业务。 设置凭证 参数列表： KEYS[1]：指定的 key 这里叫 semaphore KEYS[2]：redisson_sc:{semaphore} ARGV[1]：凭证数 3 这块 lua 脚本相对简单，直接设置一个 key 的 value 为 3。 获取凭证 参数列表： KEYS[1]：指定的 key 这里叫 semaphore ARGV[1]：要获取的凭证数，默认 1 这段 lua 脚本就是： 获取 key semaphore 的值 如果值大于等于 1（要获取的凭证数），对值进行递减 成功返回 1，失败返回 0 如果成功获取凭证，直接返回，没有获取到凭证，则自旋等待。 释放凭证 释放凭证直接对 Redis key 的值进行自增即可。 CountDownLatch 输出内容如下： 源码分析设置门闩数量 这块都大同小异。 减少门闩数量 就是对 ...

前言Redisson 还支持可重入读写锁，允许在分布式场景下，同时有多个读锁和一个写锁处于加锁状态。 使用读写锁Redisson 读写锁实现了 JUC 下的 ReadWriteLock，使用方式基本相同。 源码加锁源码基本和之前的可重入锁加锁无区别，唯一的差异就是在 Lua 脚本这里。 所以下面着重分析 Lua 脚本。 读锁源码源码地址：org.redisson.RedissonReadLock#tryLockInnerAsync 参数列表： KEYS[1]：锁名字 anyRWLock KEYS[2]：锁超时 key {锁名字}:UUID:ThreadId:rwlock_timeout 组成的字符串，{anyRWLock}:e70b1307-9ddd-43de-ac9d-9c42b5c99a0d:1:rwlock_timeout ARGV[1]：锁时间，默认 30s ARGV[2]：当前线程，UUID:ThreadId 组成的字符串，e70b1307-9ddd-43de-ac9d-9c42b5c99a0d:1 ARGV[3]：写锁名字，getWriteLockN ...

前言RedLock 红锁，是分布式锁中必须要了解的一个概念。 所以本文会先介绍什么是 RedLock，当大家对 RedLock 有一个基本的了解。然后再看 Redisson 中是如何实现 RedLock 的。 在文章开头先说明 Redisson RedLock 建议不要使用！！！在文章开头先说明 Redisson RedLock 建议不要使用！！！在文章开头先说明 Redisson RedLock 建议不要使用！！！ 重要的事情重复三遍！ 什么是 RedLock？RedLock，这块可以从网上搜到很多资料，本文也简单介绍下，当做扫盲。 单实例加锁SET resource_name my_random_value NX PX 30000 对于单实例 Redis 只需要使用这个命令即可。 NX：仅在不存在 key 的时候才能被执行成功； PX：失效时间，传入 30000，就是 30s 后自动释放锁； my_random_value：就是随机值，可以是线程号之类的。主要是为了更安全的释放锁，释放锁的时候使用脚本告诉 Redis: 只有 key 存在并且存储的值和我指定的值一样才能删除成功。 ...

前言基于 Redis 的 Redisson 分布式联锁 RedissonMultiLock 对象可以将多个 RLock 对象关联为一个联锁，每个 RLock 对象实例可以来自于不同的 Redisson 实例。 当然，这是官网的介绍，具体是什么？一起看看联锁 MultiLock 使用以及源码吧！ MultiLock 使用 按照官方文档的说法，这里 Redisson 客户端可以不是同一个。当然，一般工作中也不会说不用一个客户端吧。 加锁在阅读 MultiLock 加锁之前，小伙伴应该已经阅读过普通加锁的相关文章。 源码入口：org.redisson.RedissonMultiLock#lock() 默认超时时间 leaseTime 没有设置，所以为 -1。 这块方法太长，咱们拆分进行阅读。 基础等待时间 baseWaitTime = 锁数量 * 1500，在这里就是 4500 毫秒； leaseTime == -1 所以 waitTime = baseWaitTime，也就是 4500； while (true) 调用 tryLock 加锁，直到成功。 调用 tryLock 方法，其 ...

前言看门狗机制是在 RedissonBaseLock#scheduleExpirationRenewal 方法中，这块公平锁和非公平锁并无区别。 前文已经了解到，公平锁加锁失败之后，会将当前放到等待队列中，通过 Java 代码中的循环不断尝试获得锁。 锁释放主动释放源码：RedissonFairLock#unlockInnerAsync KEYS[1]：加锁的名字，anyLock； KEYS[2]：加锁等待队列，redisson_lock_queue:{anyLock}； KEYS[3]：等待队列中线程锁时间的 set 集合，redisson_lock_timeout:{anyLock}，是按照锁的时间戳存放到集合中的； KEYS[4]：redisson_lock__channel:{anyLock}； ARGV[1]：LockPubSub.UNLOCK_MESSAGE； ARGV[2]：锁超时时间 30000； ARGV[3]：UUID:ThreadId 组合 58f6c4a2-9908-4957-b229-283a453 ...

前言在上一篇文章中已经分析过公平锁的加锁源码，并得出结论： Redis Hash 数据结构：存放当前锁，Redis Key 就是锁，Hash 的 field 是加锁线程，Hash 的 value 是 重入次数； Redis List 数据结构：充当线程等待队列，新的等待线程会使用 rpush 命令放在队列右边； Redis sorted set 有序集合数据结构：存放等待线程的顺序，分数 score 用来是等待线程的超时时间戳。 现在看一下加锁失败被放到等待队列之后，线程是如何处理的？ 排队等锁源码入口：org.redisson.RedissonLock#lock(long, java.util.concurrent.TimeUnit, boolean)。 线程进入排队之后，在 Java 代码中会 while (true) 一直循环调用 tryAcquire，尝试获取锁。 最终还是来到 RedissonFairLock#tryLockInnerAsync 方法中。 方便起见，重新贴一下 Lua 脚本，以及脚本的参数含义。 KEYS[1]：加锁的名字，anyLock； KEYS[2 ...

前言默认的加锁逻辑是非公平的。 在加锁失败时，线程会进入 while 循环，一直尝试获得锁，这时候是多线程进行竞争。就是说谁抢到就是谁的。 Redisson 提供了 公平锁 机制，使用方式如下： RLock fairLock = redisson.getFairLock("anyLock"); // 最常见的使用方法 fairLock.lock(); 下面一起看下公平锁是如何实现的？ 公平锁相信小伙伴们看过前面的文章，已经轻车熟路了，直接定位到源码方法：RedissonFairLock#tryLockInnerAsync。 好家伙，这一大块代码，我截图也截不完，咱们直接分析 lua 脚本。 PS：虽然咱不懂 lua，但是这一堆堆的 if else 咱们大概还是能看懂的。 因为 debug 发现 command == RedisCommands.EVAL_LONG，所以直接看下面一部分。 这么长，连呼好几声好家伙！ 先来看看参数都有啥？ KEYS[1]：加锁的名字，anyLock； KEYS[2]：加锁等待队列，redisson_lock_queue: ...