记一次处理大数据而导致的内存溢出问题

问题

订单服务通过MQ进行订单同步时，刚启动可以正常消费，但是跑一会就会卡住，每次都是第8个kafka分区不行再进行消费，其他分区消费的很慢。

现象

1. 首先，CPU超高，达到百分之300多；
2. 其次，kafka消息消费很慢，尤其是第八个分区

分析

1. 由于CPU告警，首先想到JVM内存溢出了，所以先jstack出内存快照，定位导致内存溢出的代码或者可能的原因，大致过程：
   1. 使用top查看系统的资源占用情况
   2. 使用ps命令查看进程对应的是哪个程序
   3. 使用top -p PID -H 观察该进程中所有线程的资源占用
   4. 使用jstack查看线程快照
   5. 定位出现的问题
   参考地址

2. 导出内存快照，放到MAT上进行分析，定位到是一个static方法，内存溢出了
   

   但是代码逻辑没有问题，所以一时间没有找到问题。

3. 鉴于上面没有分析出来结果，又从GC日志中找结果：
   

   发现频繁的 Young GC，都是失败的。到这里还是没有很好的思路，后来通过打印日志，确认到了一个订单只有70多万个商品，再处理商品的逻辑中又使用了多层for循环进行处理，导致栈内存溢出。

结论

大数据导致内存溢出，在这个大数据处理逻辑中存在不合理代码，所以导致了内存溢出。

在排查的过程中，我们还升高了metaspace的内存，但是还是瞬间被占用满，导致CPU飙升到百分之800左右。一味堆配置并不能一劳永逸的解决问题。

工具

1. MAT 进行内存分析
2. 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