delete /exclusive/lock
不存在
释放锁
/lock
ourIndex < firstWriteIndex
curator获得公平锁
2.2.2.4 获得锁返回true
if ( predicateResults.getsTheLock() )
读锁
读节点在写节点前面
/read-0000000000
/X-0000000000
3、获得锁的请求，处理完释放锁，然后后续第一个节点收到通知，重复第2步判断
/read-0000000003
/X-0000000001
create -e /exclusive/lock
false
1.创建容器父节点以及临时顺序子节点
区别
true
源码实现
client.getData().usingWatcher(watcher).forPath(previousSequencePath); wait(millisToWait);2.2.2.5 监听上一个节点并等待
getsTheLock()
共享锁
/write-0000000006
2、判断自己是不是lock节点下，最小的节点
maxLeases=1初始化写锁跟公平锁一样
写锁
getsTheLock = ourIndex < maxLeases;2.2.2.3.3 maxLeases=1，0则可以获得锁成功
/read-0000000001
/read-0000000004
存在
getsTheLock
2.2.2.3.4 不需要监听节点
/write-0000000002
避免
获取锁
所有的连接都在对同一个节点进行监听，当服务器检测到删除事件时，要通知所有的连接，所有的连接同时收到事件，再次并发竞争，这就是羊群效应
watch
具体实现
/read-0000000007
公平锁
children.get(ourIndex - maxLeases);2.2.2.3.5 需要监听上一个节点
当前锁是否已经有其他事务创建
避免同时多个节点的并发竞争锁，缓解了服务端压力。啊实现方式所有加锁请求都进行排队加锁
b.不是。对前面的节点进行监听（watch）
是否创建成功
写节点在读节点前面
拿到所有排好序的子节点，for顺序
完成业务处理
get -w /exclusive/lock
List<String> children = getSortedChildren();2.2.2.1 获得所有的子节点并排好序
流程
1、 interProcessReadWriteLock.writeLock(); 2、interProcessReadWriteLock.readLock();
监听/等待
否
String sequenceNodeName = ourPath.substring(basePath.length() + 1);2.2.2.2 截取当前节点的名称
/X-0000000003
/X-0000000002
/write-0000000005
创建代码
获得读锁成功
2、write请求，只需要对前面的节点进行监听和互斥锁处理机制一样
children.indexOf(sequenceNodeName)2.2.2.3.1 获得当前节点的索引位置
ourIndex = index;2、如果当前节点是当前读节点名称记录当前节点的位置，跳出循环
a.是最小的，获得锁
创建/exclusive/lock
获得读锁失败，需要对最近的写节点进行监听
getsTheLock（）主要区别在于判断加锁是否成功方法
获得锁
有
2.1判断当前节点是否已经获得过锁有则锁状态加1没有执行2.2
并发问题比较严重的情况下，性能会下降的比较厉害
maxLeases = Integer.MAX_VALUE初始化读锁
非公平锁
2.只需要创建临时顺序子节点
父节点是否存在
1、read请求：如果前面的节点都是读锁，直接获取锁，如果read请求前面有写请求，则该读请求不能获得锁，即需要对前面的写节点进行监听，如果是多个写请求，则对最后的写请求进行监听
1、请求进来，直接在/lock节点下创建一个临时节点
interProcessMutex.acquire();//2.加锁
