Remember the problem analysis of oom caused by a Jap query

background

I met online some time ago OOM problem , After investigation and analysis, it is found that there is an interface that returns too much data at one time （ about 200W A result set ）, However, although there is a large amount of interface data for the problem , But the returned data has only one length 7 Of string Type field , therefore 200W About a dozen M, This is not enough to cause OOM.

make a concrete analysis

Direct analysis cannot explain the cause OOM The reason why the , That's only simulation , So I started a local Interfaces simulate the amount of data returned , Found that the memory consumption is huge , Far more than a dozen M, So the heap memory is exported for analysis .

Through heap memory analysis, we can see , Original 7 Bytes of string type , Packaged into various objects , And after being packaged, the occupied space increases dramatically , Finally achieve 1G many .

Conclusion

Finally due to JPA The encapsulation of various objects produced 1G Excessive memory consumption , Eventually lead to OOM.

therefore ,JPA Although it is very convenient to use , But that's why , If you don't understand its principle , You'll still step on many holes .

Easy to use , Principle is not easy , And the use and cherish .