背景
前段时间线上遇到OOM问题,经排查分析发现是由于有一个接口一次性返回的数据量过多导致(大约200W个结果集),不过对于问题接口数据量虽然较多,但返回的数据只有一个长度为7的string类型的字段,所以200W条大约也就十几M,这还不至于造成OOM。
具体分析
直接分析无法解释导致OOM的原因了,那只有模拟了,于是本地启了一 个接口模拟返回的数据量,发现内存消耗巨大,远远超过十几M,于是将堆内存导出来分析。
通过堆内存分析可以看出,原本7个字节的string类型,被包装成各种对象,并且被包装后占用空间剧增,最终达到1G多。
结论
最终由于JPA的各种对象封装产生了1G多的内存消耗,最终导致OOM。
所以,JPA虽然使用起来非常方便,但也正因如此,如果对其原理不了解,还是会踩不少坑的。
使用虽易,原理不易,且用且珍惜。