Ответ 1

Именно сам jconsole вызывает шаблон zig zag.

Чтобы увидеть эффект jconsole или jvisualvm вы можете написать простую java-программу только с основным контуром. Например

public static void main(String[] args) {
    while (true) {
        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
        }
    }
}

Выполните его только с небольшой кучей java -Xmx20m... Это поможет вам лучше увидеть использование кучи, потому что инструмент jstat я буду использовать далее, печатает использование в процентах.

Теперь откройте окно командной строки и выполните jstat. Вам понадобится PID java-процесса и вы сможете найти его с помощью jps -l.

jstat -gcutil <PID>

он распечатает что-то вроде этого

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00   0,00  69,34   0,00  14,48  17,19      0    0,000     0    0,000    0,000

Сосредоточьтесь на Эдем пространстве E. Значение представляет собой процентное значение емкости пространства. Посмотрите на jstat для деталей.

Если вы выполните команду снова и снова, вы увидите, что использование пространства eden не будет расти. Он сохраняется, например, на уровне 69,34. Я использую команду linux watch, например, в моих окнах, чтобы перезапустить команду с определенным интервалом. Смотрите watch.bat

Теперь откройте jconsole

jconsole <PID>

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

Вот мой вывод jstat --gcutil <PID> с интервалом в 1 секунду. Сосредоточьтесь на Эдем пространстве E.

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00   0,00  67,42   0,00  14,48  17,19      0    0,000     0    0,000    0,000
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00   0,00  67,42   0,00  14,48  17,19      0    0,000     0    0,000    0,000
# jconsole connected
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  96,88  81,64   7,57  92,26  84,87      1    0,001     0    0,000    0,001
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  96,88  84,66   7,57  92,26  84,87      1    0,001     0    0,000    0,001
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  96,88  89,70   7,57  92,26  84,87      1    0,001     0    0,000    0,001
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  96,88  91,70   7,57  92,26  84,87      1    0,001     0    0,000    0,001
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  96,88  93,70   7,57  92,26  84,87      1    0,001     0    0,000    0,001
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  96,88  95,70   7,57  92,26  84,87      1    0,001     0    0,000    0,001
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  96,88  96,70   7,57  92,26  84,87      1    0,001     0    0,000    0,001
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  96,88  98,71   7,57  92,26  84,87      1    0,001     0    0,000    0,001
# Garbage collected
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
100,00   0,00   1,13  14,06  94,75  89,26      2    0,003     0    0,000    0,003
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
100,00   0,00   3,00  14,06  94,75  89,26      2    0,003     0    0,000    0,003
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
100,00   0,00   5,75  14,06  94,75  89,26      2    0,003     0    0,000    0,003

Как вы можете видеть... После того, как jconsole подключился к процессу, пространство eden растет и растет, пока не собрано мусор. Это приводит к созданию зигзагообразного рисунка. Вот снимок от jvisualvm.

Вы обнаружите аналогичное поведение, когда будете делать то же самое с процессом tomcat. Единственным отличием будет то, что пространство eden растет очень немного, даже если никакой jconsole не подключен. Но этот незначительный рост не является причиной для зигзагообразного рисунка, который вы видите.

Вот результат jstat для моего tomcat.

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  99,80  70,33   4,81  96,85  90,10      5    0,037     0    0,000    0,037
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  99,80  70,33   4,81  96,85  90,10      5    0,037     0    0,000    0,037
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  99,80  70,43   4,81  96,85  90,10      5    0,037     0    0,000    0,037
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  99,80  70,43   4,81  96,85  90,10      5    0,037     0    0,000    0,037
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  99,80  70,43   4,81  96,85  90,10      5    0,037     0    0,000    0,037
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT

этот выход продолжается в течение 36 секунд, пока вы не увидите небольшое изменение памяти. От 70,43 до 70,53.

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  99,80  70,43   4,81  96,85  90,10      5    0,037     0    0,000    0,037
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  99,80  70,53   4,81  96,85  90,10      5    0,037     0    0,000    0,037
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0,00  99,80  70,53   4,81  96,85  90,10      5    0,037     0    0,000    0,037

Таким образом, это небольшое изменение - единственное, за что отвечают фоновые процессы tomcat.

PS: Вы также можете время от времени использовать Memory Analyzer и дайверы кучи памяти, и вы увидите, что количество используемой памяти для byte[] увеличивается, из-за сетевого трафика RMI.

Ответ 2

Вот важные моменты, чтобы понять шаблон zig zag, объясненный в связанном ответе:

• Когда коллекционер запускает его сначала пытается частичный сбор только освобождает память, которая была выделена недавно
• недавно созданные объекты, которые все еще активны, получают "продвижение"
• Как только объект будет продвинут несколько раз, он больше не будет очищен частичными коллекциями даже после того, как он будет готов к сбору
• Эти объекты, называемые tenured, очищаются только тогда, когда требуется полная сборка, чтобы сделать достаточно места для продолжения работы программы

Вопрос: Что заставляет память расти так, даже когда приложение полностью не работает?

Ответ. Есть внутренние запланированные задания, такие как автоматизация, таймеры и т.д. Или некоторый внешний мониторинг процесса, который вызывает рост памяти, когда приложение простаивает. Возможно, ваше приложение имеет одинаковое количество объектов, но некоторые могут быть больше. Например, у вас может быть несколько ArryList и некоторый StrigBuilder который продолжает увеличивать кеш.

Источники:

• Этот шаблон использования памяти указывает, что мое приложение Java теряет память?
• Проникновение памяти без увеличения количества или размера объектов

Ответ 3

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html Чтобы начать, вот полезная ссылка на "Tuning Garbage Collection с виртуальной машиной 5.0 Java TM",

Это звучит как пауза GC, делающая tomcat невосприимчивой. Прежде всего, это сборщик мусора "с низкой паузой" с опцией -XX: + UseConcMarkSweepGC.

Ответ 4

См. График Около 12: 08, Размер рабочей памяти максимальный (199 МБ).

Примерно в 12:09 сборщик мусора работает, мертвый объект собран, размер рабочей памяти составляет около 145 МБ.

Примерно в 12:12 рабочая память увеличилась, появилось много мертвых объектов, увеличение памяти с 145 МБ → 155 МБ → 165 МБ → 180 МБ ->... → 190 МБ.

Примерно в 12: 13 сборщик мусора снова работает, мертвый объект собирается, размер рабочей памяти составляет около 145 МБ.

...и так далее. Фактически, это периодический график, если не происходит особых событий.

Ответ 5

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

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

Как указано в других ответах, Tomcat может иметь свои собственные накладные расходы. Вы можете проверить это другое предположение, слушая сервлет "привет, мир" и сравнивая потребление памяти этих двух с аналогичным инструментом.