Android Libgdx Memory Leak

Question

Я использую библиотеки libgdx и android, чтобы сделать игру. У меня относительно мало опыта с любой из этих вещей. Я считаю, что у меня есть утечка памяти где-то, вызванная графикой, но я не уверен, поскольку я знаю, что libgdx резервирует большое количество кучи. Анализ MAT говорит:

The class "android.content.res.Resources", loaded by "<system class loader>", occupies 17,790,184 (31.63%) bytes. The memory is accumulated in one instance of "android.util.LongSparseArray[]" loaded by "<system class loader>". 

19 instances of "java.lang.reflect.ArtMethod[]", loaded by "<system class loader>" occupy 11,902,776 (21.16%) bytes. 

Biggest instances: 
•java.lang.reflect.ArtMethod[64707] @ 0x70b7e4b0 - 3,894,624 (6.92%) bytes. 
•java.lang.reflect.ArtMethod[52675] @ 0x70be6888 - 3,061,192 (5.44%) bytes. 
•java.lang.reflect.ArtMethod[21833] @ 0x70000ac0 - 1,336,112 (2.38%) bytes. 
•java.lang.reflect.ArtMethod[14651] @ 0x771d2d60 - 966,680 (1.72%) bytes. 
•java.lang.reflect.ArtMethod[11453] @ 0x71f964e0 - 806,432 (1.43%) bytes. 
•java.lang.reflect.ArtMethod[11047] @ 0x709b39d8 - 662,680 (1.18%) bytes. 

205 instances of "android.graphics.NinePatch", loaded by "<system class loader>" occupy 10,041,968 (17.86%) bytes. These instances are referenced from one instance of "java.lang.Object[]", loaded by "<system class loader>" 

Keywords 
java.lang.Object[] 
android.graphics.NinePatch 

32 instances of "java.lang.DexCache", loaded by "<system class loader>" occupy 6,358,016 (11.31%) bytes. 

Biggest instances: 
•java.lang.DexCache @ 0x70b50608 - 1,262,528 (2.24%) bytes. 
•java.lang.DexCache @ 0x71d2f870 - 1,177,232 (2.09%) bytes. 
•java.lang.DexCache @ 0x70bc4b60 - 903,320 (1.61%) bytes. 
•java.lang.DexCache @ 0x72178f80 - 636,768 (1.13%) bytes. 
•java.lang.DexCache @ 0x723d13f0 - 633,088 (1.13%) bytes. 

Если мой код нужен, я могу поставить его, но я не уверен, какая часть, чтобы обеспечить, так как я не уверен, где утечка. Я очень благодарен за любые советы

Answer 1

Изменения поведения GC в политике GC, например, если политика рассчитана на максимальную пропускную способность, тогда JVM будет распределять объекты до достижения Xmx. Когда он достигнет порога, GC заработает, чтобы очистить мертвый объект. Если политика GC для меньшего времени паузы a) Scavenge GC и b) Global Gc происходит до тех пор, пока не произойдет Глобальный GC, мы не можем гарантировать, будут ли удалены объекты Dead.

Лучше собирать журналы на OOM, что означает, что GC пытается как можно очистить мертвые объекты, а затем JVM выдает ошибку OOM. Если вы запустили MAT на свалке кучи в этот момент, вы можете найти подозрение на утечку соответствующим образом.

Для получения дополнительной информации о том, кто держит сильные ссылки на протекающих объектах, пишите OQL, как это, выберите * из «packagename.classname». После выполнения щелчка правой кнопкой мыши по объектам-> Путь к корням GC-> Исключить soft/Weak/Фантомные ссылки. При этом MAT предоставит информацию о том, кто держит ссылку все еще, из-за которой GC не очистил объекты.