记一次JAP查询导致OOM的问题分析

背景

前段时间线上遇到OOM问题，经排查分析发现是由于有一个接口一次性返回的数据量过多导致（大约200W个结果集），不过对于问题接口数据量虽然较多，但返回的数据只有一个长度为7的string类型的字段，所以200W条大约也就十几M，这还不至于造成OOM。

具体分析

直接分析无法解释导致OOM的原因了，那只有模拟了，于是本地启了一 个接口模拟返回的数据量，发现内存消耗巨大，远远超过十几M，于是将堆内存导出来分析。

通过堆内存分析可以看出，原本7个字节的string类型，被包装成各种对象，并且被包装后占用空间剧增，最终达到1G多。

结论

最终由于JPA的各种对象封装产生了1G多的内存消耗，最终导致OOM。

所以，JPA虽然使用起来非常方便，但也正因如此，如果对其原理不了解，还是会踩不少坑的。

使用虽易，原理不易，且用且珍惜。