不是我吹,Lambda这个坑你肯定不知道!

上周有小伙伴反馈zk连接很慢。整理出zk连接的关键逻辑如下:

public class ClientZkAgent {
  //单例模式
  private static final ClientZkAgent instance = new ClientZkAgent();
  private ZooKeeper zk; //zk客户端
  private ClientZkAgent() {
    connect(); //初始化并连接zk
  }
 
  public static ClientZkAgent getInstance() {
    return instance;
  }

 /**
  * zk常用模式: 由于zookeeper的连接是异步的,为防止zk对象在建立有效连接之前就返回,
  * 我们阻塞主线程,并通过zookeeper的EventThread在连接事件中唤醒主线程
  */
 private void connect() {
    CountDownLatch semaphore = new CountDownLatch(1);
    zk = new ZooKeeper(zkHost, timeout, watchEvent -> { // #_1
        switch (e.getState()) {
           case SyncConnected:
                semaphore.countDown();
                break;
                // 其它逻辑 ....
        }
     });
    
    semaphore.await(10000, TimeUnit.MILLISECONDS);
 }
}

上面的代码造成第一次调用ClientZkAgent.getInstance的时候,需耗时10s, 这个时间恰好跟semaphore的超时时间相当. 在此期间,整个世界好像停滞了一样。

分析

在本地重现后,通过jstack获得系统停滞期间的线程栈,发现这个时候zookeeper的EventThread有个比较奇怪的现象:

"main-EventThread" #13 daemon prio=5 os_prio=0 tid=0x000000001fe36800 nid=0xf0c in Object.wait() [0x000000002032f000]
   java.lang.Thread.State: RUNNABLE
    at com.github.dapeng.registry.zookeeper.ClientZkAgent.lambda$connect$0(ClientZkAgent.java:154)
    at com.github.dapeng.registry.zookeeper.ClientZkAgent$$Lambda$1/116211441.process(Unknown Source)
    at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:533)
    at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:508)

   Locked ownable synchronizers:
    - None

客户端实际上很快就连上了zookeeper并返回后生成了

SyncConnected事件,而且EventThread已经在回调atcher.process方法了,但似乎事件线程就一直hold在上面#_1的位置无法往下走, 同时,lambda表达式变成了ClientZkAgent的一个方法了:lambda$connect$0。

了解了一下Java中lambda的实现方式,事情水落石出了。

简而言之,jvm会把lambda表达式转换成所在类的一个方法lambda${method}${seq}(method为该 lambda 所在的方法名,例如上面的connect方法),同时通过动态代理生成一个代理类(该代理类实现了lambda表达式所代表的具体接口),在该代理类中调用lambda${method}${seq}。

在上面的例子中,生成的代理类大概如下:

final class ClientZkAgent$$Lambda$1 implements Watcher {
     final ClientZkAgent clientZkAgent;
    
     public void process(WatchedEvent event) {
        clientZkAgent.lambda$connect$0(event);
    }
}

再梳理一下:

业务线程:

1.通过静态方法ClientZkAgent.getInstance()获取实例,第一次访问的时候会触发类ClientZkAgent的装载。

2.装载过程中,装载静态成员instance,这时候会尝试创建一个ClientZkAgent对象。

3.在ClientZkAgent的构造函数中连接zk,并通过CountdownLatch进入阻塞状态。注意这时候类装载还没完成。

4.CountdownLatch超时后完成对象的初始化以及整个类的加载

zk事件线程:

SyncConnected事件触发后,调用ClientZkAgent.lambda$connect$0(event), 试图唤醒业务线程(唤醒逻辑在lambda中)。

然而这时候ClientZkAgent还没加载完,事件线程只能等待类加载流程的结束。

业务线程加载完ClientZkAgent后,事件线程完成事件的处理。

可见,在这个过程中,两个线程相互等待(类似死锁但不是死锁),直至业务线程超时后才化解这个局面。

解决

修改ClientZkAgent的初始化逻辑如下:

public class ClientZkAgent {
  //单例模式
  private static final ClientZkAgent instance = new ClientZkAgent();
  private ZooKeeper zk; //zk客户端
  private ClientZkAgent() {
  }
 
  public static ClientZkAgent getInstance() {
     if (instance.zk == null) {
            synchronized(ClientZkAgent.class) {
                if (instance.zk == null) {
                    instance.connect();
                }
            }
        }
        return instance;
  }

作者:Ever_00

来源:https://www.jianshu.com/p/b302123532b4

- END -

本文分享自微信公众号 - Java技术栈(javastack)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-10-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券