一、问题
一个查询 服务 jvm 偶现oom，容器异常退出，过会儿自动重新拉起进程，容器不变
二、时间线
20210308 怀疑是cpu飙升导致
观察cpu出现飙升， 通过 top 命令查到进程 pid 通过 top -H -p
耗cpu的线程都为GC线程，排除是cpu飙升的原因
20210311 复现oom 分析dump文件
本想通过sz 将dump文件拉到本地，但太费劲了，dump文件为16G, 即使分段也十分费劲，询问基础架构同学，提供了公司的dump文件分析工具 jifa
jifa 一个可以快速将dump文件快速上传到云端，且在远端使用MAT进行解析的工具，非常好使
将dump文件上传到S3云端，再根据返回的链接，直接跳转到jifa 平台，默认弹出刚才文件从S3导入的选择，选择导入，即会从S3导入到公司 jifa 平台。
选择对应机器的dump文件，进行在线分析，加载后即可得到线上MAT分析结果
从Dominator Tree中可看到有一个线程占用了96%的内存，且是线程中的一个ArrayList 占用着几乎这96%内存，点开发现全是 DotVO实体
该ArrayList 中存在 1.4 亿 个 DotVO实体
查该问题线程的堆栈，发现停在了 AssetsSecondInfoVO.result2VO
此处的逻辑为一个时间范围的中间数据补齐
看DotVO 中的时间 竟然还有50多万s 的时间。。。
查hive表数据，确实是有很大的时长的数据，比如视频时长为28s, 但是hive表中时间数据有16亿s的。。此时做中间时间补齐，则数据量会爆炸
询问数仓同学，是脏数据，是个已知问题
fix: 添加对下游数据正确性的校验逻辑 & 数仓同学推动上报源改造