问题
订单服务通过MQ进行订单同步时，刚启动可以正常消费，但是跑一会就会卡住，每次都是第8个kafka分区不行再进行消费，其他分区消费的很慢。
现象
- 首先，CPU超高，达到百分之300多；
- 其次，kafka消息消费很慢，尤其是第八个分区
分析
-
由于CPU告警，首先想到JVM内存溢出了，所以先jstack出内存快照，定位导致内存溢出的代码或者可能的原因，大致过程：
1. 使用top查看系统的资源占用情况
2. 使用ps命令查看进程对应的是哪个程序
3. 使用top -p [PID] -H 观察该进程中所有线程的资源占用
4. 使用jstack查看线程快照
5. 定位出现的问题
参考地址 -
导出内存快照，放到MAT上进行分析，定位到是一个static方法，内存溢出了
但是代码逻辑没有问题，所以一时间没有找到问题。 -
鉴于上面没有分析出来结果，又从GC日志中找结果：
发现频繁的 Young GC，都是失败的。到这里还是没有很好的思路，后来通过打印日志，确认到了一个订单只有70多万个商品，再处理商品的逻辑中又使用了多层for循环进行处理，导致栈内存溢出。
结论
大数据导致内存溢出，在这个大数据处理逻辑中存在不合理代码，所以导致了内存溢出。
在排查的过程中，我们还升高了metaspace的内存，但是还是瞬间被占用满，导致CPU飙升到百分之800左右。一味堆配置并不能一劳永逸的解决问题。
工具
- MAT 进行内存分析
- gceasy进行GC日志分析
参考
java程序CPU使用率高可能的原因
Mat使用详解
内存快照两种方式
- jmap 进行快照导出
输出快照
jmap -dump:format=b,file=/usr/local test1.hprof 2778
- 第二种，直接通过jstack进行查看（先top -h 进程ID - H，查询出线程ID，再转为十六进制的，进而执行下面的命令）
jstack 5739 | grep -A 100 nid=0x1802
材料
gc log
