内存飙高之列表统计


如上图所示, 20秒之内老年代内存增长较大



如上图所示, 发生MinorGC

接下来, 查询系统访问记录表 ( 根据问题发生的时间范围 ), 找到可疑的请求

          
SELECT  *
FROM operation_record
WHERE create_time >= '2023-10-11 19:24:15'
AND create_time <= '2023-10-11 19:24:50'
AND service_name = '服务名称'
          
        

再结合系统日志, 最终将问题点锁定到列表统计



以上列表统计, 请求耗时约20秒, 对应的核心SQL语句如下


查询数据量约1535315条

该问题与 内存飙高之导出功能 类似, 都是因为LIMIT值过大,查询数据量过多,链路请求耗时较久,致使数据一直'逗留'在堆内存.

以上分析基于记录和日志以及对业务的理解等.



另一方面, 也可以使用 jmap + MAT 进行问题排查

          
# 实例个数以及占用内存大小
1.jmap -histo <PID> > ./log.txt
2.grep 关键字 log.txt | sort -k3 -r | head -n 10
          
        

          
root@56549c464c-wlr99:/# grep infuq 1.txt |sort -k3 -r |head -n 10
5:         70906       15315696  com.infuq.xxx.order.out.pojo.vo.StoreCustomerOrderDetailsVO$Details
872:         108           2592  com.infuq.xxx.enums.OssType
1129:         43           1376  com.infuq.xxx.enums.apiThird.ApiReceiveTypeEnum
1339:         28            896  com.infuq.xxx.enums.apiThird.ApiPushTypeEnum
1394:         20            800  [Lcom.infuq.xxx.enums.EnvEnum;
1423:         24            768  com.infuq.xxx.enums.StorageType
1466:         23            736  com.infuq.xxx.enums.PrintTemplateType
1503:         22            704  com.infuq.xxx.enums.AppCallbackType
1543:         10            640  com.infuq.xxx.common.LoginUserInfo
1568:          6            624  com.infuq.xxx.order.out.pojo.cond.CustomerOrderAllCond
          
        

进一步分析堆转储文件. 关注Histogram / Java Basics -> Unreachable Objects Histogram

          
# 堆信息
jmap -heap <PID>
# 堆内存dump
jmap -dump:format=b,file=dump.hprof <PID>