AbstractClient里的重连机制是否有可能造成线程堵塞(连接风暴)

AbstractClient里的lazy重连机制，如下，在连接的逻辑里会使用线程锁connectLock.lock();，避免多个线程同时创建连接。
if (needReconnect && !isConnected()) {
connect();
}

protected void connect() throws RemotingException {
connectLock.lock(); //线程锁，避免多个线程同时创建连接。
.............................
}

但是这样也带来了风险，如果上游服务A分别会连接下游服务B和C，B服务因为机器或网络原因，上游服务A都无法成功连接B。
但是外部请求还在大量过来，那这个时候会表现为：A服务会因为需要去重连，而由于有线程锁，导致大量线程堆积在A服务，最后A服务瘫痪，而对于本身正常的C服务，A服务也没有机会去访问了。这种也算是连接风暴吧？

抛开使用ReconnectTimerTask的重连机制，对于这种lazy重连机制，有没有办法去避免线程堵塞呢？ 谢谢

Start by reading the AbstractClient lazy reconnect path, especially connectLock.lock(), and compare it with the ReconnectTimerTask mechanism mentioned in the issue. Reproduce concurrent requests against an unreachable downstream service while another downstream remains available. Done would require an agreed design and evidence that failed reconnects do not accumulate blocked threads or prevent access to healthy services.

Written by the indexing model from the issue text.