• 集群中随机出现。问题随机出现在该应用集群中的一个或几个实例中，无法提前预知其出现规律。

• 单机出现时间不可预知，现场捕捉困难，捕捉风险大，一般发现已经为事后，无现场第一手数据。从单个机器，或者单个实例看，则是出现概率非常低，出现时间完全随机。这使得蹲点单台机器以捕捉这个问题的思路几乎行不通，策略扩大至整个集群又可能出现稳定性及性能问题。

• 问题出现频率低。出现频率大概在一到两天一次。

• 问题表现复杂。该问题的表现很复杂，不仅从第一眼看去不合常理，JVM内部出现了大量线程在等待一把没有任何线程持有的锁。另外，问题机器的负载非常低，基本上在5%以内，相当于空载，而JVM中线程数却非常多，最多发现过接近4k个线程。

• 问题周边环境复杂。该问题出现前后，应用先后引入了rxjava、协程，应用为早期应用，服务结构复杂，而log4j问题又和网上大量的文章情形不符。

• 验证困难。理论分析完成后，无法在线上复现及验证，安全性、稳定性、数据等都不允许直接在线上验证。

step5. 资源耗尽查看

publicvoid callAppenders(LoggingEvent event) {
int writes = 0;

for(Category c = this; c != null; c = c.parent) {
// Protected against simultaneous call to addAppender, removeAppender,...
synchronized(c) {
if(c.aai != null) {
                writes += c.aai.appendLoopOnAppenders(event);
}
if(!c.additive) {
break;
}
}
}

if(writes == 0) {
        repository.emitNoAppenderWarning(this);
}
}

for(p = w ; p != NULL ; p = p->_next) {
    guarantee (p->TState== ObjectWaiter::TS_CXQ, "Invariant") ;
    p->TState= ObjectWaiter::TS_ENTER ;
    p->_prev = q ;
    q = p ;
}

// Prepend the RATs to the EntryList
if(_EntryList!= NULL) {
    q->_next = _EntryList;
_EntryList->_prev = q ;
}

step6. 框架层源码阅读

在前面步骤中大致定位了一个大的方向，线程数增加导致内存不足。接下来需要深入框架层去分析引起线程数增加的可能原因。先后对HSF、Modulet、Mtop、netty等框架进行了源码级别的分析，主要跟踪各个框架线程分配策略。其中，HSF默认设置的线程池模型扰动抗性很低。在HSF框架中，netty线程池将任务提交到HSF Provider线程池，HSF Provider线程池采用业务隔离设计，在一次对外服务中，HSF Provider大量调用HSF Consumer，而Consumer会被提交至Consumer线程池中执行。在该应用中，Provider和Consumer线程池容量比例大于200:1。

而根据业务实际，合理的比例应该在1:1附近。

失衡的线程池结构，极容易服务发生网络抖动、回环调用时使Consumer线程池服务能力下降，进而使整个应用实例对外服务能力下降。而有规律的故障不应该和无规律的抖动有关。

回环与问题出现频率之间读者可以通过概率论进行分析，假定100台机器，则每次请求会有1/100的概率发生回环，同理，每10000次请求就会发生双回环，1M次请求则是3回环。在该问题中，概率论分析和实际情况是契合的。

在研究框架层的时候，发现了回环调用对系统的危害。但是还有一个疑问需要回答，回环调用完成后，应用应该能恢复，而线上实际情况是，自恢复是个小概率事件。结合前一节可以得出一个结论，回环调用使应用Consumer线程池处理能力下降，进而使上游线程池水位逐渐提升直至被打满。而数量过度增加的线程池使得内存资源紧张，导致JVM基于磁盘运行而抢锁困难，抢锁过程的拉长使得没有任何线程持有锁这个常规状态下的瞬时状态被拉长，JVM服务能力大打折扣，而duct平台由于策略原因不能应对该问题的特殊情况导致其无法启动切流，流量照常打入JVM。于是就形成了一个恶性循环，线程数提升导致JVM进入一种非常规状态，服务能力下降，而流量照常，导致线程数很难下降。于是，JVM长时间运行在一个非常缓慢的状态，从表现上来看就是jvm挂起。下表为一个较有代表性的流量对比（实际上故障机状态跨度非常大，这两台机器较为典型而已）

实验验证

接下来，本文采用阿里PAS压测平台，对预发机器进行了压测验证。由于线上问题复杂，无法复现线上的环境，只能对其诱因进行验证。下表为压测过程中应用的性能表现。由于压测模式限制，所支持的最大tps在超时的情况下非常低，如表所示只有80左右，考虑到压测环境机器数量，回环数量还要打折。