JavaOne 2012: диагностика вашего приложения в JVM

Oracle HotSpot JDK предоставляет jcmd, инструмент командной строки, разработанный для обеспечения обратной совместимости и прямой адаптации для будущих версий Java. Он предназначен для поддержки новых инструментов и функций, которые поставляются с новыми SDK в стандартизированном подходе. На следующем снимке экрана показано, что он используется для большинства основных jps- подобных функций (Ларсен упоминал jps почти так же кратко, как я только что упомянул jcmd как « jps но более мощный»).

Как показано на jcmd выше, jcmd можно использовать как jps .

Ларсен показал некоторые удобные функции команды jcmd . У него было несколько небольших примеров Java-приложений, которые помогли ему продемонстрировать jcmd. В моих целях я запускаю jconsole в одном терминале на моей машине, а затем запускаю команды jcmd той JVM, в которой работает jconsole . На следующем снимке экрана показано, как базовый (без аргументов) вызов jcmd предоставляет информацию об этом процессе JConsole.

jcmd поддерживает выполнение процессов JVM либо по идентификатору процесса (pid), либо по имени процесса. На следующем снимке экрана показано, как запустить jcmd для процесса JConsole с этим именем и передать его, чтобы узнать, какие параметры можно запустить для этого конкретного процесса. Обратите внимание, что я безуспешно пытался запустить это с «dustin» (без существующего процесса), чтобы доказать, что jcmd действительно показывает опции, доступные для запуска процессов.

Функция, продемонстрированная на последнем снимке экрана, является одной из наиболее убедительных причин перехода от существующих инструментов командной строки, поставляемых с Oracle JDK, к jcmd . Это изображение показывает, как jcmd может предоставить список доступных параметров для каждого процесса, что обеспечивает максимальную гибкость в плане поддержки предыдущих версий или будущих версий Java, которые поддерживают разные / новые команды.

Подобно тому, как jcmd <pid> help (или заменяет pid именем процесса) перечисляет доступные операции, которые могут быть выполнены jcmd для определенного процесса JVM, этот же механизм справки может быть запущен для любой из этих перечисленных команд [с синтаксисом jcmd <pid> <command_name> help (или используйте имя процесса вместо pid)], хотя я не мог заставить это работать должным образом на моей машине Windows.

На следующем изображении показано, как на самом деле запустить эту команду для этого процесса JVM, а не просто попросить о помощи.

На двух снимках экрана, jcmd выше, я запустил jcmd для pid вместо имени процесса, просто чтобы показать, что он работает как с идентификатором процесса, так и с именем. На следующем снимке экрана показано выполнение jcmd для процесса JVM для получения флагов VM и параметров командной строки из процесса JVM (pid этого экземпляра процесса JConsole — 3556).

Выполнение команды jcmd Thread.print для поддержки процесса JVM упрощает просмотр потоков целевой JVM. Следующий вывод генерируется при запуске jcmd JConsole Thread.print против моего запущенного процесса JConsole.

Ларсен показал, как использовать информацию о jcmd предоставленную jcmd для устранения тупика.

Ларсен показал получение гистограммы классов из запущенного процесса JVM с помощью jcmd . Это делается с помощью команды jcmd <pid> GC.class_histogram . Далее показано очень маленькое подмножество его вывода (pid этого процесса JConsole 4080 на этот раз).

Ларсен также продемонстрировал jstat и несколько его полезных функций. Он продемонстрировал использование jstat -gcnew (поведение нового поколения), jstat -precompilation (статистика метода компиляции) и jstat -options (параметры отображения).

В ходе своей презентации Ларсену нужно было преобразовать десятичное число (pid?) В его шестнадцатеричное представление для сравнения его с выводом другого инструмента. Он использовал удобную команду printf '%x\n' <pid> чтобы получить шестнадцатеричное представление pid.

Ларсен продемонстрировал использование VisualVM для сравнения двух дампов кучи и просмотра дампов кучи . Он также продемонстрировал VisualVM Profiler .

Ларсен перешел от ранее описанных инструментов, предназначенных для запуска JVM, к инструментам, которые можно использовать для анализа основных файлов JVM. Он вернулся в jstack для анализа содержимого файла ядра.

Ларсен говорил об удаленном доступе к информации JVM через JMX и такие инструменты, как jconsole и jvisualvm . Он продемонстрировал, что jcmd может быть использован для запуска JMX: ManagementServer.start «с набором параметров». Ларсен считает, что VisualVM и JConsole будут использовать ManagementServer.start а не Attach API, если они будут реализованы сегодня.

jstat также может подключаться к демону удаленно с помощью jstatd . Нет шифрования или аутентификации с помощью jstatd .

jps и jcmd находят, что работает в системе, используя «известный файл для каждой JVM»: / hsperfdata_ <пользователь> / <pod> Этот файл создается при запуске JVM и удаляется при завершении работы JVM. Неиспользуемые предыдущие файлы удаляются при запуске, поэтому jps и jcmd, как и сами Java-программы, очистят эти старые.

Attach API «позволяет отправлять« команды »для выполнения в JVM», но работает только на локальном компьютере и для текущего / того же пользователя. Это то, что используют jcmd и jstack . Затем Ларсен объяснил различные механизмы использования Attach API для Linux / BSD / Solaris (использует создание временных файлов) и Windows (использует внедрение кода). Я использовал Attach API в своем посте Groovy, JMX и Attach API .

Диагностические команды — это «вспомогательные процедуры внутри JVM», которые производят «вывод текста». Они могут быть выполнены с помощью утилиты jcmd (и вскоре через JMX). У каждого из них есть средство с самоописанием: jcmd PerfCounter.print для просмотра необработанного содержимого.

Ларсен показал информативную таблицу, в которой сравниваются подходы «взаимодействия с JVM»: attach , jvmstat , JMX , jstatd и Serviceability Agent (SA). SA следует использовать как последнее средство («обычно для JVM, которая зависла») и использует «отладчик для чтения информации».

Ларсен перешел к разговору о будущих инструментах. Он начал эту часть презентации с освещения Java Flight Recorder . Java Flight Recorder представляет собой «встроенный в JVM профилировщик и трассировщик» с «низкими издержками» и «всегда включен». Другие инструменты включают в себя Java Mission Control («графический инструмент, предоставляющий очень подробные сведения о мониторинге во время выполнения»), дополнительные диагностические команды для jcmd («в конечном итоге заменяющие jstack, jmap, jinfo» по разным причинам ), JMX 2.0 («то, что мы подбираем» опять же, это было начато очень давно », улучшено ведение журналов для JVM (Предложение по расширению JVM [JEP] 158 ) и Java Discovery Protocol (предвидя предстоящий JEP для этого).

Был задан один вопрос: можно ли увидеть MBeans в VisualVM, как это можно сделать в JConsole. Как я уже писал , есть плагин VisualVM для этого.

Хотя я чувствовал себя несколько комфортно с инструментами командной строки Oracle HotSpot JDK, я был незнаком с jcmd и ценил освещение Ларсена этого. Я узнал и кое-что еще по пути. Моя единственная жалоба заключается в том, что презентация Ларсена (особенно демонстрация) была настолько быстрой и содержательной, что мне хотелось бы увидеть ее снова.

Связанная (но более старая) презентация с некоторым содержимым доступна по адресу http://www.oracle.com/javaone/lad-en/session-presentations/corejava/22260-enok-1439100.pdf.

Ссылка: JavaOne 2012: диагностика вашего приложения в JVM от нашего партнера по JCG Дастина Маркса в блоге Inspired by Actual Events .