原因：应用启动后，在未做调用时cpu占用20%-30%

这肯定是有问题的，严重影响压测质量和存在线上风险，所以开始排查。

下面将详细写出排查和分析过程。

1，确认问题

登录 三台服务器，top (或者vmstat 1)一下，查看cpu占用情况：

三台机器都很高，而且还未有调用量， 有问题。

登录IMSI销售接口服务器对比查看：

可以确定应用不正常了。开始解决。

2，解决过程

• 因为是cpu高，内存不高，所以确定是线程问题，所以去到问题服务器抓取线程
  
  ./jstack  xx >> /home/admin/jstack.log    （xx 是应用的进程号）
  将线程日志搞到跳板机 再搞到本地分析。
  
  线程分析工具用的是 jca，打开查看：
  
  
  而正常的应用:
  
  
  问题应用runnable 线程竟然有900多，waite线程不会占用cpu资源，暂时不用分析。点击详细：
  
  

      

          发现大量的NettyClientSelector， 嗯？ 这应该是hsf的线程吧！（这里分析是错的！！！） 然而忽略了最重要的MQ-AsyncArrayDispatcher-Thread-XX，这个后面会详细写。

          然后后面做了一些对hsf的配置优化，进入edas的后台可以查看到有大量的无用的consumer，这对edas的压力是非常大的，随着以后服务越来越多，配置越来越多，会对线上存在隐患，于是进行精简，抽取本地的 consumer配置文件。

           再次上线， 分析。。 发现问题依旧， 崩溃。  从头再来。 

• 还是找到问题进程
  
  我们看看这个进程里的哪些线程在占用cpu：
  top -p 进程id -H
  
   (这个图是解决问题后截取的，没解决时，cpu占比每个都在0.6-1左右，是非常高的)
  
  红框里是线程id，是10进制的，jstack.log 里是以16进制展示的，所以需要转换，到文件里找到对应的线程号。

          

发现查了好多都是 AsyncArrayDispatcher$AsyncRunnable.run 这个方法。

继续分析这个东西是干嘛的，找代码。

发现这是一个守护线程，应该是为每个新创建的topic 提供一些系统的记录功能。

瓶颈期到了，想找找哪里应用到了这个类，可是都在阿里的jar里，找起来很费劲，而且不确定在哪，有可能还会在潘多拉里，找了很久的class源码，无果，这里耽误了很久的时间。

后来转换方向，因为imsi_sale是正常的，所以确定不会是底层的BUG导致的，还是把目标转向应用本身的配置，而且跟MQ相关的。

查看mq相关的配置，惊奇的发现，竟然这么多无用配置。

 。。。

将近 100多，期间我们找了天源的人给看了topic的默认线程数是5个，这么算来也得启了几百的无用线程，跟问题线程数也很接近。

到底是不是呢？ 又找了代码，发现在 base_impl包里真的有：

 

不得不说隐藏的很深，有点坑。 这些东西应该是放在配置文件里，我们能看见的地方的。

好吧，终于确定问题了，精简配置文件，上线， 解决！

注： 其他应用也存在这样的问题， 都需要修复一下。