Обнаружение утечек памяти из дампа кучи JVM

Одной из основных причин популярности Java является сборщик мусора. Во время выполнения любой объект, который недоступен из корня GC, будет автоматически уничтожен и его память будет использована повторно (рано или поздно). Наиболее распространенными корнями GC являются локальные переменные в методах и полях статических данных; объект достижим, когда корень GC указывает на него напрямую или через цепочку других объектов. Таким образом, ни один объект в Java не может действительно «утечь», то есть стать недоступным для работающей программы, но при этом израсходовать память — во всяком случае, ненадолго. Итак, почему «утечка памяти» остается одной из распространенных проблем с памятью в приложениях Java? Если вы задаетесь вопросом об этом или когда-либо пытались понять, почему используемая память вашего приложения продолжает расти, читайте дальше.

Вкратце, утечки памяти в Java не являются настоящими утечками — это просто структуры данных, которые становятся неконтролируемыми из-за ошибок или неоптимального кода. Можно утверждать, что они являются побочным эффектом силы языка и его экосистемы. В прежние времена, предшествовавшие Java, написание большой программы на C ++ было медленным, иногда болезненным процессом, который требовал серьезных усилий слаженной группы разработчиков. В настоящее время, с богатым набором классов библиотек JDK и еще более богатым выбором стороннего кода с открытым исходным кодом, с мощными IDE и, прежде всего, мощным, но все же «прощающим» языком, которым стала Java, ситуация изменилась. Свободная группа или даже один разработчик могут быстро собрать действительно большое приложение, которое работает. Подвох? Они, вероятно, будут иметь ограниченное понимание того, как именно это приложение, или, по крайней мере, некоторые его части, работают.

К счастью, большая часть таких проблем может быть решена с помощью модульных тестов. Хорошо протестированные библиотеки и код приложения обеспечивают хорошее приложение. Однако есть одно предупреждение: модульные тесты редко пишутся для моделирования реальных объемов данных и / или реальной продолжительности выполнения. Это основная причина, по которой может проникнуть неоптимальный код, вызывающий утечку памяти.

Одним из распространенных источников утечек памяти являются кэши памяти, которые используются, чтобы избежать медленных операций, таких как повторное извлечение одних и тех же объектов из базы данных. В качестве альтернативы, некоторые данные, сгенерированные во время выполнения, такие как история операций, могут периодически выгружаться на диск, но также сохраняться в памяти, снова для ускорения доступа к нему. Повышение производительности за счет предотвращения повторных медленных чтений из внешнего хранилища за счет некоторой дополнительной памяти, как правило, является разумным выбором. Но если ваш кеш не имеет ограничений по размеру или других механизмов очистки; объем внешних данных высок по сравнению с кучей JVM; и если приложение работает достаточно долго — у вас могут возникнуть проблемы. Во-первых, паузы GC станут более частыми и займут больше времени. Затем, в зависимости от некоторых вторичных факторов, существует два сценария. В первом случае приложение скоро зависнет с OutOfMemoryError, Во втором случае, который обычно возникает, когда при каждом вызове GC может быть восстановлено небольшое количество памяти, приложение может столкнуться с другой проблемой: оно не будет аварийно завершаться, но оно будет проводить почти все свое время в GC, создавая впечатление зависания. Второй сценарий может быть трудно диагностировать, если не используется размер используемой кучи. Но даже если разворачивается первый, как вы узнаете, какие структуры данных отвечают за это?

К счастью, поскольку эта проблема не нова, с течением времени были разработаны различные инструменты для диагностики утечек памяти. Они подразделяются на две большие категории: инструменты, которые непрерывно собирают информацию во время выполнения, и инструменты, которые анализируют один снимок памяти JVM, называемый дампом кучи.

Инструменты, которые собирают информацию, непрерывно работают через инструменты (изменение) кода приложения и / или активацию внутренних механизмов сбора данных в JVM. Примерами таких инструментов являются Visual VM или Mission Control , оба из которых поставляются с JDK. В принципе, такие инструменты более точны в выявлении утечек памяти, поскольку они могут различать большие, неизменные структуры данных и структуры, которые продолжают расти со временем. Однако сбор этой информации на достаточно подробном уровне часто приводит к высоким накладным расходам времени выполнения, что делает этот метод непригодным для использования в производственном или даже предпроизводственном тестировании.

Таким образом, второй вариант: анализ одного дампа кучи и выявление структур данных, которые являются «кандидатами на утечку», действительно привлекателен. Взятие дампа кучи приостанавливает работающую JVM на относительно короткий период. Создание дампа занимает около 2 секунд на 1 ГБ используемой кучи. Так, если, например, ваше приложение использует 4 ГБ, оно будет остановлено на 8 секунд. Дамп может быть jmap  получен по требованию (с помощью  утилиты JDK) или в случае сбоя приложения с помощью  OutOfMemoryError  (если JVM была запущена с параметром   -XX:+HeapDumpOnOutOfMemoryError командной строки).

Дамп кучи — это двоичный файл размером с кучу вашей JVM, поэтому его можно читать и анализировать только с помощью специальных инструментов. Существует целый ряд таких инструментов, как с открытым исходным кодом, так и коммерческих. Наиболее популярным инструментом с открытым исходным кодом является Eclipse MAT; есть также VisualVM и некоторые менее мощные и менее известные инструменты. Коммерческие инструменты включают профилировщики Java общего назначения: JProfiler и YourKit, а также один инструмент, специально созданный для анализа дампа кучи, под названием JXRay.

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

Давайте рассмотрим пример сейчас. Простая Java-программа ниже имитирует ситуацию, когда (а) большая часть памяти занята большими неизменными объектами, и (б) также имеется большое количество потоков, причем все они поддерживают идентичные, относительно небольшие структуры данных (  ArrayListв нашем примере), которые продолжают расти.

import java.util.ArrayList;
import java.util.List;

public class MemLeakTest extends Thread {

  private static int NUM_ARRS = 300;
  private static byte[][] STATIC_DATA = new byte[NUM_ARRS][];
  static {  // Initialize unchanging static data
    for (int i = 0; i < NUM_ARRS; i++) STATIC_DATA[i] = new byte[2000000];
  }

  private static final int NUM_THREADS = 20;

  public static void main(String args[]) {
    MemLeakTest[] threads = new MemLeakTest[NUM_THREADS];
    for (int i = 0; i < NUM_THREADS; i++) {
      threads[i] = new MemLeakTest();
      threads[i].start();
    }
  }

  @Override
  public void run() {  // Each thread maintains its own "history" list
    List<HistoryRecord> history = new ArrayList<>();
    for (int count = 0; ; count++) {
      history.add(new HistoryRecord(count));
      if (count % 10000 == 0) System.out.println("Thread " + this + ": count = " + count);
    }
  }

  static class HistoryRecord {
    int id;
    String eventName;

    HistoryRecord(int id) {
      this.id = id;
      this.eventName = "Foo xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" + id;
    }
  }
}

> java -Xms1g -Xmx1g -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC \
 -XX:OnOutOfMemoryError="kill -9 %p" -XX:+HeapDumpOnOutOfMemoryError \
 -XX:HeapDumpPath="./memleaktest.hprof" MemLeakTest