背景
故事是这样的,好像是测试在进行代扣流程的压力测试,然后群里有人@了:“怎么这个dubbo服务又调不通了?”
打开群里的截图粗略看下来好像是报的服务调用失败的错误,@了运维小哥哥说是清结算前置应用宕掉了,内存溢出了
问题定位与分析
于是赶紧找运维小哥哥将服务器上的堆dump文件弄了下来,对于堆内存溢出的分析我们还是通过jdk自带的jvisualvm来进行分析,导出来的hprof还是挺大的,花了近30-40秒才加载完毕,查看类的当时快照的情况发现应用中有几个业务model对象和数据库连接对账实例数排在前列
然后通过jvisualvm的概要发现触发OOM的入口
上图溢出的原因显示的是因为mybatis在构造解析sql的时候,这时我们接着往下看
发现导致该OOM的流程是清结算应用中有一个异步处理的流程(上层支付系统在实时处理完支付结果后有一个异步操作,将此笔支付订单通过mq队列的方式同步给清结算系统;而清结算系统侧则会有一个消费过程:从mq中取出一笔笔的支付订单然后落地到清算系统中用来做后续的清分