Мониторинг использования памяти с Java SE 5

Одним из преимуществ Java по сравнению с C++ стала концепция автоматического управления памятью. А именно - виртуальная машина Java имеет нить сбора мусора, которая освобождает неиспользуемую память, когда куча расходует все предоставленную память.

Реализация стратегии сборки мусора зависит от производителя виртуальной машины, но общим является то, что этот процесс может быть довольно ресурсоемким. Виртуальная машина от Sun определяет 2 режима для сборки мусора: Легкий «copy» и Тяжелый «Mark-Sweep-Compact».

«Легкая» сборка выполняется относительно быстро и затрагивает перемещение данных в куче во время выполнения других потоков. «Тяжелая» сборка является более основательной, приостанавливающей выполнение всех потоков на время своей работы. Основная цель оптимизации производительности кучи – уменьшить частоту и длительность «тяжелых» сборок.

Виртуальная машина от IBM реализует другую архитектуру и различает режимы сборки мусора по состоянию кучи. Сборки мусора градируются от минимально влияющих чисток (выполняемых на mark фазе, выполняемой одновременно с другими нитями) до наихудшего сценария полного цикла mark-sweep-compact, т. н. сборки «stop-the-world».

 

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

 

До релиза платформы Java SE 5, в возможности мониторинга входили:

• •        шнформация о размере и использовании кучи, получаемые через вызовы методов класса java. lang. Runtime;
• •        Детальный журнал сборки мусора, получаемый путем установки соответствующих параметров загрузки JVM, которые сообщали ей о необходимости журналирования подробной информации о сборке мусора каждый раз, когда она происходила;
• •        Проприетарные API виртуальной машины, такие как jvmstat от Sun;
• •        Рискованные нестандартные пути, такие как присоединение DLL или разделяемого объекта в адресное пространство виртуальной машины с целью чтения память процесса.

 

Каждая из этих стратегий имеет свои плюсы и минусы, касающиеся накладных расходов и трудностeй реализации, и, как результат, отсутствие единой оптимальной стратегии.

 

Одним из преимуществ мониторинга производительности серверов приложений является то, что все основные производители освоили Java Management Extensions (JMX) и выдают информацию мониторинга в форме Managed Beans (MBeans). С выходом Java SE 5, к самой виртуальной машине были добавлены реестр JMX и поддержка MBeans. С этого времени все прелести этого подхода доступны и настольным приложениям.

В дополнение к этому, спецификация Java SE 5 определяет новые классы и интерфейсы в пакете java. lang. management, показывающие статистику виртуальной машины времени выполнения. Небольшое количество этих интерфейсов реализовано в виде managed beans, отражающих информацию о поведении памяти виртуальной машины, а также память процесса отведенную под кучу и остальную. В этой статье мы затронем 3 интерфейса:

 

• 1.    MemoryMXBean
• 2.    MemoryPoolMXBean
• 3.    GarbageCollectionMXBean

 

Все управляющие MBeans можно загрузить с помощью класса-помощника - java. lang. management. ManagementFactory, предоставляющего набор статических методов, возвращающих запрашиваемые Mbeans.

• •         MemoryMXBean memorymbean = ManagementFactory. getMemoryMXBean();
• •         List<MemoryPoolMXBean> mempoolsmbeans = ManagementFactory. getMemoryPoolMXBeans();
• •         List<GarbageCollectorMXBean> gcmbeans = ManagementFactory. getGarbageCollectorMXBeans();

 

MemoryMXBean предоставляет информацию об использовании памяти, отведенную под кучу и остальную. Конкретнее, он делает это с помощью следующих 2 методов:

• •         MemoryUsage getHeapMemoryUsage()
• •         MemoryUsage getNonHeapMemoryUsage()

 

Эти методы возвращают экземпляры java. lang. management. MemoryUsage, в котором определены 4 ключевых атрибута:

• •        Init: начальное количество памяти, затребованное JVM у операционной системы в момент загрузки;
• •        Used: количество памяти, используемое в данный момент;
• •        Commited: количество памяти, гарантированно доступное для использования; оно может изменяться со временем но всегда должно быть больше или равно объему использованной памяти;
• •        Max: максимальное количество памяти, которое может быть использовано для кучи и для других нужд.

 

The MemoryPoolMXBean сообщает информацию о специализированных пулах памяти в JVM. Для тех, кто знаком с кучей в ВМ Sun, эти пули включают Eden Space, Survivor Space, Tenured Generation и Permanent Generation.

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

• •        Текущее использование;
• •        Пиковое использование;
• •        Использование во время последней сборки мусора;
• •        Тип раздела – куча или нет;
• •        Менеджеры памяти, управляющие данным разделом, например "Copy" или "MarkSweepCompact".

 

GarbageCollectorMXBean предоставляет информацию о времени сборок и их количестве по каждому из пулов памяти.

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

 

На листинге представлен класс, показывающий использование памяти в виртуальной машине перед и после создания миллиона строковых переменных.

Его выполнение начинается с получения и вывода информации через MemoryMXBean.

В данном случае минимальное и максимальное значение размера кучи было установлено в 32Мб с использование следующих параметров при загрузке:

-Xms32m –Xmx32m

 

Использованная память уменьшилась с 236Кб до 213Кб после выполнения, что, как мы установим, явилось результатом нескольких сборок мусора.

 

Информация о сборках мусора получена от GarbageCollectorMXBean. Виртуальная машина Sun в стандартной конфигурации реализует 2 сборщика мусора: “Copy” и “MarkSweepCompact”.

В этом участке вывода программы вы можете увидеть, что создание и разрушение миллиона строк вылилось в 63 сборки типа “copy”, что заняло 12 миллисекунд времени. Если мы изменим код так, чтобы не разрушать строки между итерациями, то мы увидим как происходят сборки “MarkSweepCompact”.

 

В конце мы выводим информацию о разных пулах памяти, используя MemoryPoolMXBeans. Он возвращает несколько пулов в виртуальной машине от Sun:

• •        Code Cache: содержит память, используемую для компиляции и хранения native кода;
• •        Eden Space: пул, память которого выделяют поз создание большинства объектов;
• •        Survivor Space: пул, содержащий объекты, которые не были разрушены во время уборки Eden space;
• •        Tenured Gen: пул, содержащий долгоживущие объекты;
• •        Perm Gen: содержит данные JVM, включающие статические члены класса;
• •        Perm Gen [shared-ro]: только чтение
• •        Perm Gen [shared-rw]: чтение-запись

 

Из приведенного мы можем увидеть, что для 32Мб кучи под Windows  с установками по умолчанию под Eden отведено 2112KB, каждая из двух survivor областей получила по 192Кб и TenuredGen получила оставшиеся 30272KB.

Все в сумме составило 32768KB кучи. шнтересно, что PermGen получает в начале 8Мб и может вырасти до 64Мб. Собирая эту информацию, вы можете анализировать поведение кучи. Для тех из вас, кто склонен к таким занятиям, Mbeans предоставляют интерфейс оповещения, информацию о котором вы найдете в Java SE 5 Javadocs.

 

Если вы хотите получать всю эту информацию в режиме реального времени, JDK от Sun содержит Java Monitoring and Management Console (JConsole), которая может подключаться к уже запущенной виртуальной машине и получать и выводить эту информацию. Вы можете прочитать больше о ней в статье Mandy Chung на сайте Sun: Using JConsole to Monitor Applications.

 

Заключение

Мониторинг использования памяти в Java 1. 4 и ниже был похож на черную магию.

С появлением Java SE 5 и открытых интерфейсов, таких как JMX, задача существенно упростилась. С устранением технических трудностей при получении этой информации, вы можете сконцентрироваться на настоящих задачах, таких как анализ этих показателей.