跟进 watcher.materialize(event.getState(), event.getType(), 会追到下面的代码
case NodeDataChanged: // todo node中的data改变和 nodeCreate 都会来到下面的分支 case NodeCreated: synchronized (dataWatches) { // todo dataWatches 就是刚才存放 path : watcher 的map // todo dataWatches.remove(clientPath) 移除并返回clientPath对应的watcher , 放入 result 中 addTo(dataWatches.remove(clientPath), result); }上面的dataWatches 就是保存path+watcher set的map, 上面的操作是移除并返回指定的watcher,这也说明了,为什么zk原生客户端添加的watcher仅仅会回调一次
EventThread是如何消费waitingEvents的EventThread是一条守护线程, 因此它拥有自己的不断在运行的run方法,它就是在这个run方法中对这个队列进行消费的
@Override public void run() { try { isRunning = true; // todo 同样是无限的循环 while (true) { // todo 从watingEvnets 中取出一个 WatcherSetEventPair Object event = waitingEvents.take(); if (event == eventOfDeath) { wasKilled = true; } else { // todo 本类方法,处理这个事件,继续进入,方法就在下面 processEvent(event); } if (wasKilled) synchronized (waitingEvents) { if (waitingEvents.isEmpty()) { isRunning = false; break; } } } } catc继续跟进它的processEvent(event),最终会在这个方法中调用下面的代码,这里的watcher就是我在本篇博客的开始位置添加进去的watcher,至此打完收工
watcher.process(pair.event);