作者:程序员小航 2021-07-10 10:02:30
大数据
分布式 在了解了加锁和锁重入之后,最需要了解的还是在分布式场景下或者多线程并发加锁是如何处理的?
三江侗网站制作公司哪家好,找创新互联!从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设等网站项目制作,到程序开发,运营维护。创新互联2013年至今到现在10年的时间,我们拥有了丰富的建站经验和运维经验,来保证我们的工作的顺利进行。专注于网站建设就选创新互联。
在了解了加锁和锁重入之后,最需要了解的还是在分布式场景下或者多线程并发加锁是如何处理的?
先来看结果,在多线程对 /locks/lock_01 加锁时,是在后面又创建了新的临时节点。
这块在加锁方法 CreateBuilderImpl#pathInForeground 中已经介绍过
这里判断 /locks/lock_01 路径已经存在,会直接创建新的临时顺序节点。
真正判断锁是否获取成功,其实是在 LockInternals#attemptLock 方法中的 internalLockLoop 方法中。
internalLockLoop 方法的主要作用是判断加锁结果,以及获取锁失败时,对其他节点的监听。
是否获取锁的代码在 StandardLockInternalsDriver#getsTheLock
这块就是判断是否为最小节点,因为在 getSortedChildren 中已经对所有节点排序,所以方法中的 List children 是有序的。
maxLeases 是在 InterProcessMutex 初始化的时候,指定的值为 1。
最终这里的结果是,判断自己是不是最小,不是最小,就将 pathToWatch 设置为前一个节点。
只监听自己的前一个节点,可以避免羊群效应!
为什么要进行等待呢?
因为是为了防止无效自旋,因为这里有监听机制,会监听上一个节点是否释放。
这块是 ZooKeeper 的 Watcher 监听机制,在节点释放的时候,会进行回调,然后使用 Java 的 notifyAll 方法通知所有的 wait 线程。然后这里的 while trye 会继续执行,重新检查是否获得锁等。
本文主要介绍了基于 ZooKeeper 的分布式锁框架 Curator 在并发场景下的锁竞争问题。
重点需要了解的是:
本文转载自微信公众号「程序员小航」,可以通过以下二维码关注。转载本文请联系程序员小航公众号。
新闻标题:ZooKeeper分布式锁Curator源码之三:可重入锁并发加锁
文章位置:http://www.mswzjz.cn/qtweb/news35/552935.html
攀枝花网站建设、攀枝花网站运维推广公司-贝锐智能,是专注品牌与效果的网络营销公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 贝锐智能