问题背景
中小件装卸服务uat时，cpu报99，想到是新接了的mq，于是将接mq改为只打印日志，cpu恢复正常
由于业务正在进行uat验证，所以没有办法排查，只能等到夜深人静没人用的时候将逻辑都打开，让机器报警排查问题
一开始是觉得mq的数据太多接不过来，于是给uat的机器进行扩容，发现每个机器的cpu都很高，先将机器缩容，通过ump查看每分钟的mq的数据并不多，
然后下载jstack查看发现好多线程接收新增的两个mq的数据，于是查看了mq2的文档，发现consumer有个maxConcurrent属性,maxConcurrent 是单分区组上面的最大并发数,如果不配置这个是可以动态调整的，配置之后就不会自动调整了，于是将maxConcurrent设置为1，部署uat，发现依然没有解决问题
于是在行云上面执行了top命令，查看了当前cpu哪个进程最高
这里可以看到进程282占用cpu最高
再通过进程id找到占用最高的线程id top -H -p pid,得到如下信息
可以看到前面的线程占用cpu较高，找出其中一个将线程数转化成16进制
再通过jstack得到当前程序的快照，找到这个线程，查看堆栈信息，找到了问题所在
将57行的数据放到static块中问题解决
最终效果：
标签：查看,uat,问题,排查,线程,mq,cpu From： https://www.cnblogs.com/lilyjia/p/17932714.html