重写完Dubbo-admin以后，出现如下问题，经常性的过一阵以后呢，Dubbo就接受不到zk的回调通知了，经过查看堆栈发现了如下问题，zookeeper的回调线程被lock住了，因此它是接受不到zk信息发生的变化的。

    网络链接
    image.png

    image.png
    既然有wait，就有notify :( so bad

    暂时的处理方案
    1、将zookeeper的版本从3.5.4.beta降低到3.4.13，curator从4.0.1版本降低到2.13.0，待观察(和服务器zk保持一致，并没有理论依据说明降低版本会生效)

    实际的notify其实是在这里被调用

    1.     private void finishPacket(Packet p) {
    2.         if (p.watchRegistration != null) {
    3.             p.watchRegistration.register(p.replyHeader.getErr());
    4.         }
    6.         if (p.cb == null) {
    7.             synchronized (p) {
    8.                 p.finished = true;
    9.                 p.notifyAll();//here
    10.             }
    11.         } else {
    12.             p.finished = true;
    13.             eventThread.queuePacket(p);
    14.         }
    15.     }

    finishPacket 在两次被调用，分别是
    image.png
    字面意思上看是丢包了或者是读取消息成功了。 我们是内容丢包的概率不大，但是不排除.

    • 丢包
    • 响应结果
      • 查看代码发现readResponse就是一个正常的NIO实现，如果网络畅通应该是么得这种问题的，这个时候就得抓包看看其他的信息了。

    不过我们这里有一个特殊的地方，就是zk的服务器地址不是常规的ECS地址，而是使用的SLB的地址，常规的方式是z1.example.com:2181,z2.example.com:2181,z3.example.com:2181, 因为我们使用的是SLB地址，而z1,z2,z3都是指向的某一个IP，不确定这里有没有问题

    因为连zk的进程比较多，所以通过源端口来进行抓包

    1. tcpdump port 33342 -w xxx.cap

    由于应用刚刚启动，抓包显示是正常的. 等过一天在来抓包看看是否正常…
    ——————————————————2021-03-01—————————————————-
    image.png

    2021-03-02 查看堆栈，这个堆栈是正常的，2个zk的线程都在正常的工作。 下午在查看一次 :)
    2021-03-03 查看堆栈，完美,问题复现失败…

    虽然问题复现失败了，这次的分析稍微提升了自己对于的堆栈和线程阻塞的理解，算是意外之喜.. 😄 😊 😂