前言
在了解了加锁和锁重入之后,最需要了解的还是在分布式场景下或者多线程并发加锁是如何处理的?
1并发加锁
先来看结果,在多线程对 /locks/lock_01 加锁时,是在后面又创建了新的临时节点。
这块在加锁方法 CreateBuilderImpl#pathInForeground 中已经介绍过
这里判断 /locks/lock_01 路径已经存在,会直接创建新的临时顺序节点。
真正判断锁是否获取成功,其实是在 LockInternals#attemptLock 方法中的 internalLockLoop 方法中。
加锁结果及监听
internalLockLoop 方法的主要作用是判断加锁结果,以及获取锁失败时,对其他节点的监听。
获取父节点 /locks/lock_01 下的所有子节点,按照从小到大排序,判断自己是不是获取到锁,没有获取到就监听自己前一个节点; 支持设置超时时间,超时直接返回失败; 不支持设置超时时间或者还没有超时,则直接 wait 等待。
是否获取锁的代码在 StandardLockInternalsDriver#getsTheLock
这块就是判断是否为最小节点,因为在 getSortedChildren 中已经对所有节点排序,所以方法中的 List children 是有序的。
maxLeases 是在 InterProcessMutex 初始化的时候,指定的值为 1。
最终这里的结果是,判断自己是不是最小,不是最小,就将 pathToWatch 设置为前一个节点。
只监听自己的前一个节点,可以避免羊群效应!
为什么要进行等待呢?
因为是为了防止无效自旋,因为这里有监听机制,会监听上一个节点是否释放。
这块是 ZooKeeper 的 Watcher 监听机制,在节点释放的时候,会进行回调,然后使用 Java 的 notifyAll 方法通知所有的 wait 线程。然后这里的 while trye 会继续执行,重新检查是否获得锁等。
2总结
本文主要介绍了基于 ZooKeeper 的分布式锁框架 Curator 在并发场景下的锁竞争问题。
重点需要了解的是:
为了避免羊群效应,临时顺序节点,加锁失败后监听的是前一个节点; 为了避免无效自旋,这里使用了 Java 的 wait/notifyAll 机制; 可以看出,默认加锁就是公平锁。
Ubuntu是一个以桌面应用为主的Linux操作系统。它是一个开放源代码的自由软件,提供了一个健壮、功能丰富的计算环境,既适合家庭使用又适用于商业环境。Ubuntu将为全球数百个公司提供商业支持。 ...
查看全文Docker采取了一种保守的方法来清理未使用的对象(通常称为“垃圾收集”),例如图像,容器,卷和网络:除非您明确要求Docker这样做,否则通常不会删除这些对象。这可能会导致Docker使用额外的磁盘空...
查看全文新浪科技讯 北京时间5月27日晚间消息,据报道,四位知情人士今日透露,亚马逊、微软和谷歌这三大云计算服务提供商,正在竞争波音公司(Boeing)价值10亿美元的云服务合同。 这些...
查看全文新浪科技讯 北京时间5月27日晚间消息,据报道,多位知情人士今日称,继加州、纽约州和华盛顿州之后,马萨诸塞州和宾夕法尼亚州的总检察长也加入到对亚马逊的反垄断调查中。 如今,越来越...
查看全文
您好!请登录