原因：应用启动后，在未做调用时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包里真的有：
不得不说隐藏的很深，有点坑。 这些东西应该是放在配置文件里，我们能看见的地方的。
好吧，终于确定问题了，精简配置文件，上线， 解决！
注： 其他应用也存在这样的问题， 都需要修复一下。
