Утечка памяти: как решить

Много прочитав о MAT, я использовал свой дамп кучи для анализа проблемы утечки памяти. Вот ошибка отчета об утечке:

Поток org.apache.tomcat.util.threads.TaskThread @ 0x6d8be0a30 http-bio-8443-exec-115 хранит локальные переменные общим размером 3 695 816 440 (89,03%) байт. .

Память накапливается в одном экземпляре "java.lang.Object[]", загружаемом "'‹'загрузчиком системных классов'>".

Сводка дерева доминаторов показывает следующее:

org.apache.tomcat.util.threads.TaskThread @ 0x6d8be0a30 http-bio-8443-exec-115 SH:112 RH:3,695,816,440 Prct:89.03% java.util.ArrayList @ 0x6da437cd8 SH:24 RH:3,695,668,184 Prct:89.03% java.lang.Object[1823230] @ 0x77da34ee8 SH:7,292,936 RH:3,695,668,160 Prct:89.03% com.cjs.persistence.dto.SomeDTO @ 0x76f631650 SH:360 RH:2,264 Prct:0.00% com.cjs.persistence.dto.SomeDTO @ 0x750ed8f88 SH:360 RH:2,264 Prct:0.00% ...

Путь к корню GC показывает сам поток. Я не могу найти, что вызывает это и почему эти списки DTO сохраняются и как их очистить. Любые советы очень ценятся.


person sMajeed    schedule 21.04.2015    source источник


Ответы (1)


На самом деле, мы не могли бы помочь вам таким образом, если вы хотите решить проблемы с утечкой, вам нужно получить много входных данных, таких как GC подробности, дампы потоков и т. д.

Тем не менее, я мог бы предложить сделать следующее:

Из ваших входных данных я могу сказать, что ваша проблема с утечкой вызвана локальной переменной, которая была заполнена с помощью определенного метода, и, похоже, у нее есть цикл, сложный бизнес или любой другой фактор.

Обратите внимание: корнем GC для локальной переменной всегда будет сам ее родительский поток.

В этом случае вам нужно получить stacktrace этого потока, он покажет вам, что именно делает этот поток, так что вы можете начать свое расследование с них.

person Salah    schedule 21.04.2015
comment
Спасибо за ваш ответ. Трассировка стека указывает на метод, который извлекает некоторые объекты из базы данных и заполняет SomeDTO, и ничего больше. - person sMajeed; 21.04.2015