Try English version of Quizful



Раздаем бесплатные Q! подробности в группе Quizful.Alpha-test
Партнеры
Рекрутерам: Прескрининг кандидатов about
Топ контрибуторов
loading
loading
Знаете ли Вы, что

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

Лента обновлений
ссылка 20:57:36
Комментарий от Recrut_rf:
Спасибо, сохранил функцию, может пригодится когда - ни...
ссылка 20:53:59
Добавлен вопрос в тест ASP.NET - Основы
ссылка 08:41:09
Комментарий от Krosster:
Гарний сайт для новачків. Правда деякі питання підступн...
ссылка Apr 22 22:06
Добавлен вопрос в тест SQL - Средний уровень
ссылка Apr 22 10:13
Комментарий от Entrery:
вроде выбрал ООП в сишарпе, а тут вопросы по джаве...
Статистика

Тестов: 153, вопросов: 8596. Пройдено: 402470 / 1961091.

Анализируем утечки памяти в Java приложениях, используя VisualVM

head tail Статья
категория
Java
дата25.08.2009
авторmismatch
голосов11

Введение

Утечка памяти — это болезнь и OutOfMemoryError (OOM) — симптом её. Но не все OOM обязательно указывают на утечку памяти. OOM может возникнуть в результате генерации большого количества локальных переменных — в частности при огромном количестве одновременных запросов (в случае серверного приложения). С другой стороны необязательно все утечки памяти проявляются в виде OOM — особенно в случае настольных и клиентских приложений (те, которые не работают длительное время без перезагрузки).

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

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

Утечка памяти в куче

1) Запустите приложение. Используйте последний доступный JDK (JDK 1.6 на данный момент). В новых версиях java существенно улучшились инструменты отладки. Выполняйте различные действия в запущенном приложении по несколько раз, чтобы определить, какое из них приводит к утечке памяти.

java visual vm

Добейтесь стабильного состояния приложения. Наблюдайте за размером кучи на протяжении некоторого времени. Если «размер кучи после полной сборки мусора» (именно полной) каждый раз растет, это указывает на утечку памяти. И для этого наблюдения мы можем использовать VisualVM. Теперь мы определили операцию, приводящую к утечке памяти — значит, если мы будем выполнять эту операцию неоднократно, получим OOM. (Как быть, если мы не смогли определить операцию, приводящую к утечке памяти?) Дальше мы предполагаем, что эта операция выполняется беспрерывно.

2) Установите VisualVM (https://visualvm.dev.java.net/download.html). Для этого достаточно распаковать архив в любом удобном месте. Инсталляция необходима лишь в случае, если вы используете более ранние версии JDK, чем 1.6 update 7.

3) Запустите VisualVM

4) Присоединитесь к приложению — все запущенные на виртуальной машине java процессы перечисленны в левой части (должно отображаться имя главного класса). Вы можете сделать двойной щелчок по интересующему вас. В правой части четыре вкладки — нас интересует монитор и профилировщик.

java visual vm

5) Перейдите на вкладку профилировщика. Выберите флажок настроек для отображения различных опций. Перейдите на вкладку настроек памяти. Выберите ‘record allocations stack traces’. Снимите флажок настроек — это закроет панель с настройками (все изменения будут автоматически сохранены).

java visual vm

6) Теперь нажмите кнопку ‘memory’ - запустится профилирование памяти. Подождите несколько секунд — это займет некоторое время. Появится панель с вкладками для различных классов и информацией о количестве экземпляров, общим размером в байтах.

7) Подождите пока состояние приложения стабилизируется.

8) Сделайте снимок объектов, нажав кнопку вверху панели с вкладками (смотрите скриншот). Полученный снимок отобразится в правой части, а в левой его метка.

java visual vm

9) Подождите некоторое время, чтобы произошла утечка памяти. Сделайте снимок также, как и в предыдущем шаге. Теперь у нас есть два снимка.

10) Выберите оба снимка в левой части и щелкнете правой кнопкой мышки и выберите ‘compare’. В правой части должна появится вкладка с результатом сравнения. На этой вкладке отобразятся те элементы, для которых произошло увеличение значений за период, прошедший между первым и вторым снимком. Самый верхний элемент и есть скорее всего причиной утечки памяти.

java visual vm

11) Снова перейдите на вкладку профилировщика. Выберите определенный на предыдущем шаге элемент. Щелкните по нему правой кнопкой мышки и выберите пункт ‘Take snapshot and show allocation stack traces’. Сгенерируется еще один снимок. На этот раз в правой части окна также будет отображена вкладка с трассировкой стека. На ней перечислены различные места, где данный элемент инстанциируется, а также его процентный вклад в общее использование памяти.

java visual vm

12) Подождите пока произойдет еще несколько утечек памяти. Сделайте еще несколько снимков.

13) Получите дамп кучи, используемой приложением. Это можно сделать, щелкнув правой кнопкой мыши по приложению и выбрав ‘heap dump’.

14) Теперь вернемся к соответствующим снимкам с трассировками стека. Сравните эти два снимка со стеками трассировки. Определите методы, которые значительно отличаются по вкладу в общее использование памяти. Это места, в которых инстациирование объектов приводит к утечкам памяти.

java visual vm

15) Перейдите к вкладке дампа кучи в правой части. Найдите окно Classes. Дважды щелкните по элементу, определенном на 10-м шаге. Отобразятся экземпляры этого класса. Выберите экземпляр, который вы считаете виновным в утечке памяти (просто интуиция). Посмотрите в правой части. Раскройте окно. Вы увидите объекты, ссылающиеся на эти экземпляры. Здесь причина утечки памяти.

16) По элементам, определенным на 10-м шаге и информации, полученной на 14-м и 15-м шагах, мы можем решить проблему с утечкой памяти. Мы нашли объект, приводящий к утечке, место его создания и объекты, ссылающиеся на него.

------------
Перевод статьи, занявшей первое место в Java VisualVM Blogging Contest
Оригинал статьи - Analyzing Memory Leak in Java Applications using VisualVM

Если Вам понравилась статья, проголосуйте за нее

Голосов: 11  loading...
admin   mismatch   alexis112   ilia   giroy   acnipih   JinSem   Shved90   lonely   Testikusik11   SamTan