ИСПОЛЬЗОВАНИЕ ФЛАГОВ ЗАПУСКА ВИРТУАЛЬНОЙ МАШИНЫ JAVA

АННОТАЦИЯ

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

Ключевые слова: Java, Java Development Kit, JVM HotSpot, флаги оптимизации.

Современные JVM [1] отлично справляются с работой по эффективному и стабильному запуску приложений Java (и приложений на других совместимых языках). Адаптивное управление памятью, сборка мусора, своевременная компиляция, динамическая загрузка классов, оптимизация блокировок – лишь малая часть той магии, которая возможна, но которая редко напрямую касается среднестатистического программиста. Во время выполнения JVM оптимизирует способ обработки приложения или его частей на основе непрерывных измерений и профилирования.

Даже при таком уровне автоматизации (или, скорее, из-за такого перебора автоматизации), важно, чтобы JVM по-прежнему предоставляла адекватные возможности для внешнего мониторинга и ручной настройки. В случае ошибок или низкой производительности должны иметься инструменты для вмешательства. Тем не менее несмотря на всю автоматическую оптимизацию, широкий набор инструментов для ручной настройки также является одной из сильных сторон современных JVM. Особый интерес представляют флаги командной строки [2], которые можно передать JVM при запуске приложения. Некоторые JVM предоставляют несколько сотен таких флагов, и, работая с ними без достаточных знаний, легко “заблудиться”.

Существует два типа JVM HotSpot, а именно «сервер» и «клиент». Серверная виртуальная машина использует больший размер для кучи [3], параллельный сборщик мусора и более агрессивно оптимизирует код во время выполнения. Клиентская виртуальная машина более консервативна, что сокращает время запуска и объем памяти. Благодаря концепции, называемой «эргономика JVM», тип JVM выбирается автоматически во время запуска на основе определенных критериев, касающихся доступного оборудования и операционной системы.

Если Вас не устраивает предварительно выбранная JVM, то можно использовать флаги -server и -client, чтобы указать использование сервера и клиента VM соответственно. Несмотря на то, что изначально виртуальная машина сервера предназначалась для длительных серверных процессов, в настоящее время она часто демонстрирует более высокую производительность, чем клиентская виртуальная машина, и во многих автономных приложениях. Стоит отметить, что в 32-битных системах для возможности запуска серверного варианта виртуальной машины требуется HotSpot JDK, в своё время 32-разрядная JRE поставляется с клиентской виртуальной машиной.

Как узнать, какая версия Java и какой тип JVM используется при выполнении java-команд? При более чем одной установке Java в системе всегда есть небольшой риск запустить неправильную JVM, не заметив этого. Особенно популярны в этом отношении предустановленные JVM в различных дистрибутивах Linux.

К счастью, существует флаг -version, который выводит некоторую информацию об используемой JVM в стандартный вывод.

Рисунок 1. Запуск виртуальной машины Java с флагом “-version”

В выходных данных отображается номер версии Java (15.0.2) и точный идентификатор сборки используемой виртуальной машины (build 15.0.2+7-27). Также отображается имя (HotSpot) и тип (Server VM), также отображается, что JVM работает в смешанном режиме (mixed mode). Этот режим выполнения является режимом HotSpot по умолчанию и означает, что JVM динамически компилирует байтовый код в собственный код во время выполнения. Мы также узнаем, что общий доступ к данным класса включен (sharing). Совместное использование данных классов — это подход, при котором системные классы JRE хранятся в кэше только для чтения, который используется как общий ресурс загрузчиком классов всех процессов Java. Совместное использование данных классов, может быть, выгодно для производительности по сравнению с многократным чтением всех данных классов из архивов jar.

Флаг -version завершает работу JVM сразу после печати вышеуказанных данных. Однако существует аналогичная версия флага -showversion, которую можно использовать для получения того же вывода, но затем продолжить и выполнить данное приложение Java. Таким образом, -showversion является полезным дополнением к командной строке практически любого приложения Java. Вы никогда не знаете, когда вам вдруг понадобится какая-то информация о JVM, используемой конкретным (аварийным) Java-приложением. Добавляя -showversion при запуске, мы гарантируем, что эта информация будет доступна всякий раз, когда она нам понадобится.

Два флага -Xint и -Xcomp не слишком актуальны для нашей повседневной работы, но очень интересны для того, чтобы узнать что-нибудь о JVM. Флаг -Xint заставляет JVM выполнять весь байт-код в интерпретируемом режиме, что сопровождается значительным замедлением выполнения (обычно в 10 или более раз). Напротив, флаг -Xcomp вызывает прямо противоположное поведение, то есть JVM компилирует весь байт-код в собственный код при первом использовании, тем самым применяя максимальный уровень оптимизации. Это звучит хорошо, потому что полностью избегает медленного интерпретатора. Однако многие приложения немного пострадают от использования -Xcomp, даже если падение производительности несопоставимо с падением в результате -Xint. Причина в том, что, устанавливая -Xcomp, мы не позволяем JVM использовать свой JIT-компилятор [4] в полной мере. Компилятор JIT создает профили использования методов во время выполнения, а затем оптимизирует отдельные методы (или их части) шаг за шагом, а иногда и предположительно, для реального поведения приложения. Некоторые из этих методов оптимизации, например, оптимистическое предсказание ветвлений, не могут быть эффективно применены без предварительного профилирования приложения. Другой аспект заключается в том, что методы компилируются только тогда, когда они доказывают свою актуальность, то есть образуют некую горячую точку в приложении. Методы, которые вызываются редко (или даже только один раз), продолжают выполняться в интерпретируемом режиме, что снижает затраты на компиляцию и оптимизацию.

Обратите внимание, что у смешанного режима также есть собственный флаг -Xmixed. В последних версиях HotSpot по умолчанию используется смешанный режим, поэтому нам больше не нужно указывать этот флаг.

Особенно для длительно работающих приложений, придерживайтесь настроек JVM по умолчанию и позвольте JIT-компилятору полностью использовать свой динамический потенциал. В конце концов, JIT-компилятор - один из самых сложных компонентов JVM. Последние достижения в его оптимизации - основная причина, по которой Java в наши дни больше не считается медленной.

Список литературы:

1. Материал из Википедии – свободной энциклопедии, Java Virtual Machine – электронный ресурс, URL: https://en.wikipedia.org/wiki/Java_virtual_machine (дата обращения: 11.02.2021)
2. Java HotSpot VM Options // Oracle – электронный ресурс, URL: https://www.oracle.com/java/technologies/javase/vmoptions-jsp.html (дата обращения: 11.02.2021)
3. Материал из Википедии – свободной энциклопедии, Куча (память) – электронный ресурс, URL: https://ru.wikipedia.org/wiki/Куча_(память) (дата обращения: 11.02.2021)
4. Материал из Википедии – свободной энциклопедии, Just-in-time compilation – электронный ресурс, URL: https://en.wikipedia.org/wiki/Just-in-time_compilation (дата обращения: 11.02.2021)