1. 背景
上周有小伙伴反馈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的超时时间相当. 在此期间，整个世界好像停滞了一样。
2. 分析
在本地重现后，通过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已经在回调Watcher.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);
}
}
再梳理一下:
业务线程:
- 通过静态方法
ClientZkAgent.getInstance()获取实例，第一次访问的时候会触发类ClientZkAgent的装载。 - 装载过程中，装载静态成员instance，这时候会尝试创建一个
ClientZkAgent对象。 - 在
ClientZkAgent的构造函数中连接zk，并通过CountdownLatch进入阻塞状态。 注意这时候类装载还没完成。 -
CountdownLatch超时后完成对象的初始化以及整个类的加载
zk事件线程:
-
SyncConnected事件触发后，调用ClientZkAgent.lambda$connect$0(event), 试图唤醒业务线程(唤醒逻辑在lambda中)。 - 然而这时候
ClientZkAgent还没加载完，事件线程只能等待类加载流程的结束。 - 业务线程加载完
ClientZkAgent后，事件线程完成事件的处理。
可见，在这个过程中，两个线程相互等待(类似死锁但不是死锁)，直至业务线程超时后才化解这个局面。
3. 改进
修改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;
}
