前言

在了解了加锁和锁重入之后，最需要了解的还是在分布式场景下或者多线程并发加锁是如何处理的？

并发加锁

先来看结果，在多线程对 加锁时，是在后面又创建了新的临时节点。

这块在加锁方法 中已经介绍过

这里判断 路径已经存在，会直接创建新的临时顺序节点。

真正判断锁是否获取成功，其实是在 方法中的 方法中。

加锁结果及监听

方法的主要作用是判断加锁结果，以及获取锁失败时，对其他节点的监听。

是否获取锁的代码在

这块就是判断是否为最小节点，因为在 中已经对所有节点排序，所以方法中的 是有序的。

是在 初始化的时候，指定的值为 1。

最终这里的结果是，判断自己是不是最小，不是最小，就将 pathToWatch 设置为前一个节点。

只监听自己的前一个节点，可以避免羊群效应！

为什么要进行等待呢？

因为是为了防止无效自旋，因为这里有监听机制，会监听上一个节点是否释放。

这块是 ZooKeeper 的 Watcher 监听机制，在节点释放的时候，会进行回调，然后使用 Java 的 notifyAll 方法通知所有的 wait 线程。然后这里的 while trye 会继续执行，重新检查是否获得锁等。

总结

本文主要介绍了基于 ZooKeeper 的分布式锁框架 Curator 在并发场景下的锁竞争问题。

重点需要了解的是：

相关推荐