Мониторинг Java-приложений с помощью бортового самописца
Узнайте о регистраторе полетов Java, который собирает информацию о событиях в JVM во время выполнения приложения Java
1. Обзор
В этом уроке мы рассмотрим Java Flight Recorder, его концепции, основные команды и способы его использования.
2. Утилиты мониторинга Java
Java – это не просто язык программирования, а очень богатая экосистема с множеством инструментов. JDK содержит программы, которые позволяют нам компилировать наши собственные программы, а также отслеживать их состояние и состояние виртуальной машины Java в течение всего жизненного цикла выполнения программы.
Папка bin дистрибутива JDK содержит, среди прочего, следующие программы, которые можно использовать для профилирования и мониторинга:
В этом уроке мы сосредоточимся на бортовом самописце Java. Этого нет среди инструментов, упомянутых выше, потому что это не автономная программа. Его использование тесно связано с двумя вышеперечисленными инструментами — средствами управления полетами Java и средствами диагностических команд.
3. Бортовой самописец Java и его основные концепции
Чтобы использовать JFR, мы должны активировать его. Мы можем достичь этого двумя способами:
У JFR нет автономного инструмента. Мы используем Java Mission Control (JMC), который содержит плагин, позволяющий визуализировать данные, собранные JFR.
JFR имеет две основные концепции: события и поток данных. Давайте кратко обсудим их.
3.1. События
JFR собирает события, которые происходят в JVM при запуске приложения Java. Эти события связаны с состоянием самой JVM или состоянием программы. Событие имеет имя, метку времени и дополнительную информацию (например, информацию о потоке, стеке выполнения и состоянии кучи).
3.2. Поток данных
События, которые собирает JFR, содержат огромное количество данных. По этой причине, по замыслу, JFR достаточно быстр, чтобы не мешать программе.
JFR сохраняет данные о событиях в одном выходном файле, flight.of.
Как мы знаем, операции дискового ввода-вывода довольно дороги. Поэтому JFR использует различные буферы для хранения собранных данных перед сбросом блоков данных на диск. Все может стать немного сложнее, потому что в один и тот же момент программа может иметь несколько процессов регистрации с различными параметрами.
В некоторых редких случаях JFR может не очистить данные (например, при слишком большом количестве событий или в случае отключения электроэнергии). Если это произойдет, JFR попытается сообщить нам, что в выходном файле может отсутствовать часть данных.
4. Как использовать бортовой самописец Java
JFR является экспериментальной функцией, поэтому ее использование может быть изменено. На самом деле, в более ранних дистрибутивах мы должны активировать коммерческие функции, чтобы использовать их в производстве. Однако, начиная с JDK 11, мы можем использовать его, ничего не активируя. Мы всегда можем ознакомиться с официальными примечаниями к выпуску Java, чтобы узнать, как использовать этот инструмент.
Как мы уже упоминали выше, существует два способа активации JFR. Когда мы активируем его одновременно с запуском приложения, мы делаем это из командной строки. Когда приложение уже запущено, мы используем инструмент диагностических команд.
4.1. Командная строка
После успешной компиляции мы можем запустить программу со следующими опциями:
где путь к файлу класса – это точка входа приложения *.class файл.
4.2. Инструмент диагностических Команд
До JDK 11, чтобы иметь возможность активировать JFR таким образом, мы должны запустить приложение с разблокированными коммерческими функциями:
После запуска приложения мы используем его идентификатор процесса для выполнения различных команд, которые имеют следующий формат:
Вот полный список диагностических команд:
Каждая команда имеет ряд параметров. Например, команда JFR.start имеет следующие параметры:
5. Бортовой самописец Java в действии
Давайте теперь продемонстрируем JFR в действии, используя пример программы.
5.1. Пример программы
Без выполнения этого кода мы можем обнаружить потенциальный недостаток: цикл while приведет к высокой загрузке процессора и памяти. Давайте используем JFR, чтобы увидеть эти недостатки и, возможно, найти другие.
5.2. Начать Регистрацию
Сначала мы компилируем нашу программу, выполнив следующую команду из командной строки:
Теперь мы запустим программу со следующими опциями:
5.3. Визуализация Данных
Его главный экран показывает нам информацию о том, как программа использовала процессор во время своего выполнения. Мы видим, что процессор был сильно загружен, что вполне ожидаемо из-за цикла while :
На этой вкладке мы можем обнаружить еще один недостаток нашего примера программы: метод java.util.ArrayList.grow(it) вызывался 17 раз, чтобы увеличить емкость массива каждый раз, когда не хватало места для добавления объекта.
В более реалистичных программах мы можем увидеть много другой полезной информации:
6. Заключение
В этой статье мы познакомили вас с темой мониторинга и профилирования Java-приложения с помощью регистратора полетов Java. Этот инструмент остается экспериментальным, поэтому мы должны обратиться к его официальному сайту для получения более полной и свежей информации.
Использование Java Flight Recorder с OpenJDK 11
Java Flight Recorder (JFR) раньше был коммерческим дополнением к Oracle JDK. Поскольку он недавно был открыт с Java Mission Control, все, кто использует OpenJDK 11, теперь могут бесплатно устранять неполадки в своих приложениях Java с помощью этого превосходного инструмента. JFR, будучи ранее проприетарным решением, может быть менее известен тем, кто полагается на предыдущие версии OpenJDK. Поэтому я подумал, что стоит написать свежий пост об использовании JFR с OpenJDK 11.
1. Обзор
1.1. О Java Flight Recorder
JFR — это инструмент профилирования, используемый для сбора данных диагностики и профилирования из работающего приложения Java. Снижение производительности незначительно и обычно ниже 1%. Для краткосрочных приложений эти издержки могут быть выше этого, потому что JFR требует некоторого времени прогрева при запуске.
Диагностика неисправных приложений с помощью JFR может значительно сократить время разрешения. На первый взгляд может показаться, что аномалия разворачивается и, наконец, наступает до того момента, когда это приводит к смерти приложения. Конечно, не все проблемы настолько серьезны. JFR собирает данные о запущенных потоках, циклах GC, блокировках, сокетах, использовании памяти и многом другом.
1.2. Java Flight Recorder вышел с открытым исходным кодом
Марк Рейнхольд из Oracle хотел ускорить продвижение Java и получил вдохновение от некоторых операционных систем Linux, выпуск которых составлял шесть месяцев. Я думаю, что он мог подумать об Ubuntu, хотя он не упомянул это именно. Тем не менее, Java SE начиная с версии 9 действительно имеет предсказуемый шестимесячный цикл выпуска.
Как следствие, JFR стал открытым исходным кодом и упростил процесс выпуска благодаря единой движущейся базе кода, которая делает OpenJDK более привлекательной для разработчиков.
1.3. Различия в упаковке JFR
1.4. Java Mission Control также был открытым исходным кодом
JMC также недавно был открыт с открытым исходным кодом, и это означает, что теперь весь набор инструментов (JFR + JMC) доступен любому, кто использует OpenJDK 11. На момент написания первой версии 7 JMC с открытым исходным кодом еще не достиг GA, но ранние сборки доступа обеспечены.
2. Использование регистратора полета
Я не использовал JFR в производстве постоянно, потому что это было бы нарушением лицензии Oracle JDK. Для развития все может быть использовано в соответствии с моими знаниями. Таким образом, пользователи Oracle JDK — без контракта на поддержку — должны были в конечном итоге вынуждены воспроизводить проблемы производительности локально на своих машинах разработки.
Хорошо, тогда давайте посмотрим код. Это будет простая демонстрация самых основ Java Flight Recorder, и я намеренно затрудняюсь, чтобы дать нам что-то для отладки.
Для демонстрации классического OOME мы могли бы просто добавить новые объекты в коллекцию. Я выбрал этот, потому что часто вижу этот конкретный образец в производстве. То есть существует два (или более) компонента, и некоторые из них создают новые объекты, а некоторые из них потребляют эти объекты. Проблема связана с тем, что емкость этого внутреннего буфера, через который взаимодействуют компоненты, потенциально неограниченна.
Когда я говорю «потенциально неограниченный», я имею в виду, что размер буфера, умноженный на размер среднего объекта, настолько велик и через некоторое время он просто пожирает все пространство кучи. Часто это может OutOfMemoryError часы, дни или неделю, но OutOfMemoryError произойдет в конце концов.
Часто разработчики считают, что OutOfMemoryError в журналах наверняка отражает ошибку программирования и утечку памяти. Иногда анализ дампа кучи подтверждает или опровергает это с уверенностью, но есть случаи, когда он не черный или белый, и вы просто не можете сказать. JFR с историческими данными приходит на ресурс в этих случаях.
2.1. Включить JFR
Мы можем ожидать OutOfMemoryError от короткой программы выше, и это займет некоторое время, но это произойдет. С помощью JFR мы можем изучить ход времени и характеристики ошибки с полной информацией о времени GC, использовании ЦП и многом другом.
Я использую эти настройки отладки в производстве. В этом смысле эти аргументы JVM также служат примечанием для меня, когда они мне понадобятся, я найду их здесь.
Что касается JFR, это выделенная часть (строки 5-11). По умолчанию ни максимальный размер записи, ни максимальный возраст или записанные данные не ограничены. Я экспериментировал с различными настройками, и применение maxage и maxsize оказалось полезным. В более ранних версиях JDK у JFR было больше настроек, но они упростили их в версии 11.
Управление Java Flight Recorder
Не так давно в мире Java случилось грандиозное событие. Во всех актуальных версиях OpenJDK стал доступен Java Flight Recorder (или просто JFR).
JFR – это механизм легковесного профилирования Java-приложения. Он позволяет записывать и в последствии анализировать огромное количество метрик и событий, происходящих внутри JVM, что значительно облегчает анализ проблем. Более того, при определённых настройках его накладные расходы настолько малы, что многие (включая Oracle) рекомендуют держать его постоянно включённым везде, в том числе прод, чтобы в случае возникновения проблем сразу иметь полную картину происходившего с приложением. Просто мечта любого SRE!
Раньше этот механизм был доступен только в коммерческих версиях Java от корпорации Oracle версии 8 и более ранних. В какой-то момент его реимплементировали с нуля в OpenJDK 12, затем бекпортировали в OpenJDK 11, которая является LTS-версией. Однако вот OpenJDK 8 оставалась за бортом этого праздника жизни. Вплоть до выхода апдейта 8u272, в который наконец-то тоже бекпортировали JFR. Теперь все (за редким исключением) пользователи OpenJDK могут начинать использовать эту функциональность.
Но вот незадача: большая часть документации в интернете относится к старой, коммерческой, версии JFR и во многом не соответствует версии, которая присутствует в OpenJDK. Да и та, что есть, весьма скудная и не способствует пониманию того, как это всё использовать.
В предлагаемой вашему вниманию статье я расскажу, как управлять работой JFR и как его настраивать.
Активация через параметры JVM
Активировать JFR можно несколькими путями. Один из них – задать соответствующие параметры при запуске Java-приложения. Для этого необходимо использовать два параметра:
Каждая из этих опций может быть дополнена настройками, например:
задаёт путь к файлу, куда будет записана вся собранная JFR информация после завершения записи (или остановки приложения).
Опций может быть несколько. В таком случае они разделяются запятыми (без пробелов!).
Посмотрим, какие есть настройки у каждой из этих опций и для чего они нужны.
XX:StartFlightRecording
XX:FlightRecorderOptions
Примеры использования
Минимально возможный пример запуска Java с JFR выглядит так:
В результате в консоль будет выдано сообщение:
В параметрах мы не указали никаких настроек. Т.о., в силу быстрого завершения выполнения (сразу после вывода версии Java) мы не сможем получить результаты в виде файла. Данные JFR будут накапливаться в памяти и пропадут при остановке приложения.
Чтобы это исправить, можно задать дополнительные опции:
В результате по окончании работы приложения записанные данные будут сброшены в файл recording.jfr в текущем каталоге.
Вместо имени файла, можно указать имя каталога:
Как было отмечено ранее, по умолчанию JFR накапливает все снятые данные в памяти в течение всей работы приложения. Полностью память при этом под записанные данные использоваться не будет. JFR имеет ряд настроек, ограничивающих максимальное использование памяти. Но что делать, если хочется производить запись в течение длительного времени, не забивая при этом память?
В таком случае можно использовать набор настроек, позволяющих сбрасывать записанные данные по частям на диск:
Т.о., мы получаем конфигурацию, которую можно задавать для долго работающих приложений и при этом иметь возможность ретроспективно увидеть, что конкретно происходило с приложением на момент, когда ему «поплохело».
Единственный существенный момент, который остался за скобками, — настройка снимаемых метрик JFR.
Файл конфигурации профиля JFR
По умолчанию с OpenJDK поставляется два преднастроенных профиля:
Оба профиля тщательно подобраны разработчиками OpenJDK и лежат в каталоге JAVA_HOME/jre/lib/jfr для OpenJDK 8 или JAVA_HOME/lib/jfr для OpenJDK 11+.
Активировать их можно с помощью опции, например settings=profile.jfc :
Во многих ситуациях этого может оказаться достаточно, но не во всех. Дело в том, что в этих двух профилях остаётся отключённым очень большое количество метрик, которые могут очень помочь в тех или иных ситуациях. Например, в default.jfc практически отключён сбор информации о потреблении памяти, хотя он не даёт заметного пенальти, но при этом весьма полезен для понимания того, куда расходуется память приложения.
Т.о., становится понятно, что для своих частных случаев имеет смысл формировать отдельный, специально заточенный под себя файл с настройками. Но править его вручную – дело неблагодарное. Поэтому рекомендуется воспользоваться инструментом Java Mission Control (JMC), который умеет не только просматривать файлы, записанные JFR, но и управлять профилями записи этих файлов.
Скачать дистрибутив JMC можно, например, с сайта компании BellSoft.
В открывшемся окне можно задать название профиля, его описание и настройки в упрощённом виде.
Но если упрощённых настроек не хватает, можно перейти в подробный режим, нажав кнопку Advanced :
Перейдя в такой режим настроек, можно включить дополнительные метрики для записи. Например, можно включить метрики:
Как показано на скриншоте выше. Значимого пенальти по скорости это не создаёт, зато позволяет оценить, где и чем мусорит приложение в памяти, что часто позволяет находить весьма нетривиальные проблемы.
Важно понимать, как работает сбор данных метрик, чтобы правильно оценивать показываемые ими данные. JFR не пишет информацию о создании каждого объекта. Вместо этого, делается более хитрый ход: JVM не выделяет память напрямую из кучи, а отрезает от последней равные фрагменты и распределяет их по каждому потоку в отдельности. Локальное выделение объектов из таких локальных блоков происходит гораздо быстрее и без лишних блокировок. Так вот, в момент, когда очередной такой блок заканчивается, JFR записывает, при создании объекта какого класса это произошло, а также может записать стек, чтобы понять, в каком месте программы это произошло. Т.о., получается, что нельзя увидеть абсолютно всю информацию о выделяемых объектах, но при достаточно длительной работе приложения можно получить адекватную картину происходящего просто по закону больших чисел.
Также важно понимать, что если были внесены и сохранены какие-либо изменения в этом окне, доступ к простому виду настроек будет потерян. Настройки всегда будут открываться только в подробном виде.
После создания своего профиля работы JFR его можно экспортировать в отдельный файл и использовать в настройках запуска, указав путь к этому файлу:
Управление JFR через командную строку (jcmd)
Но что делать, если приложение уже работает и надо запустить запись JFR? Или приостановить запись по какой-то причине? Или ещё что-то сделать?
Для этого можно воспользоваться штатной утилитой OpenJDK — jcmd. Например, запустить JFR можно следующей командой:
— PID процесса JVM, в котором необходимо запустить JFR. В ответ будет выдана информация о том, что JFR запущено и куда именно будет записан файл с результатом:
В целом видно, что при использовании jcmd доступны все те же самые опции, что и при запуске через параметры JVM, но некоторые опции имеют другие имена, поэтому далее они будут рассмотрены подробнее.
Утилита jcmd может выполнять несколько команд, связанных с JFR. Рассмотрим их по порядку.
JFR.start
Можно использовать следующие опции:
| Опция | Описание | Умолчание |
|---|---|---|
| name | Имя, которое может использоваться для идентификации запускаемой записи, например: «My Recording» | |
| settings | Имя или путь к конфигурации профиля записи. Имя может быть profile или default. См. JRE_HOME/lib/jfr | |
| delay | Задержка перед началом записи. Размерности значения: (s)econds, (m)inutes), (h)ours) или (d)ays, например: 5h. | 0 |
| duration | Продолжительность записи. Размерности значения: (s)econds, (m)inutes, (h)ours или (d)ays, например: 300s. | 0 |
| filename | Файл, куда следует внести результат записи, например: «/home/user/My Recording.jfr». | |
| disk | Запись должна вестись на диск, а не в памяти. | |
| maxage | Максимальный промежуток времени, в течение которого будут сохраняться на диске записываемые данные. Размерности значения: (s)econds, (m)inutes, (h)ours или (d)ays, например: 60m или 0 для отсутствия ограничения | 0 |
| maxsize | Максимальное количество данных, сохраняемых при записи на диск. Размерности значения: (k)B, (M)B или (G)B, например: 500M или 0 для отсутствия ограничения. | 0 |
| dumponexit | Сбросить записанные данные на диск, если JVM прекращает работу. | |
| path-to-gc-roots | Сохранять пути до корней GC у объектов. | false |
JFR.configure
JFR.stop
Останавливает запись и сбрасывает записанные данные в файл, указанный при старте или непосредственно при вызове данной команды.
| Опция | Описание |
|---|---|
| name | Имя записи, которую необходимо остановить |
| filename | Файл, куда нужно записать результат записи, например: «/home/user/My Recording.jfr». |
JFR.dump
Эта команда позволяет получить записанные данные, не останавливая саму запись. Ещё одной отличительной особенностью данной команды от JFR.stop является возможность сохранить не всю запись, а только интересующую её часть.
JFR.check
Выводит информацию об активных записях JFR. Данная команда полезна, чтобы понять, запущена ли уже запись JFR в JVM и требуется ли её запускать или можно смотреть информацию в уже запущенной. А также чтобы убедиться, что записываются интересуемые события (метрики) JFR.
| Опция | Описание | Умолчание |
|---|---|---|
| name | Имя записи, для которой запрашивается информация. Если не указано, то будет выведена информация для всех активных записей. | |
| verbose | Вывести полную информацию по записываемым событиям JFR. | false |
Примеры использования
Разберём типовой сценарий использования jcmd для работы с JFR.
В качестве подопытного буду использовать запущенный Java Mission Control, который ранее использовался для формирования настроек записи.
Прежде всего посмотрим, не запущена ли уже запись JFR:
И получаем результат (сокращено для наглядности):
Видно, что интересующие меня метрики отключены. Но не беда: можно запустить отдельную запись в том же процессе JVM с интересующими меня настройками:
Видно, что запись успешно запустилась.
Также можно посмотреть список всех записей:
И убедиться, что наша запись работает параллельно с ранее запущенной:
Через 10 минут мы получим файл с результатами записи, который готов к открытию и изучению в Java Mission Control.
Но что делать, если есть необходимость включить запись на постоянной основе и иметь возможность анализировать результаты за сутки или более? В таком случае памяти на все записываемые данные может не хватить, а значит, нужно активировать их сброс на диск по мере записи. Для этого можно предварительно выполнить команду:
Таким образом мы зададим каталог, куда будет скидываться записываемая информация. Плюс мы устанавливаем размер одного файла. Т.е. данные будут писаться фрагментами по 20 Мб, каждый из которых будет самодостаточным, и его можно будет просматривать в JMC независимо от всех остальных файлов.
В результате выполнения команды увидим следующий ответ:
Т.е. настройки установлены успешно. Теперь можно запускать непрерывную запись JFR:
Самым главным моментом в данном примере является включение записи на диск, вместо хранения данных в памяти. Также ограничиваем максимальное время хранения данных одними сутками, а размер – 10 Гб. Как минимум для того, чтобы диск не переполнился.
После этого в каталоге /path/to/disk/cahce/2020_12_03_16_58_40_28534 начнут появляться файлы с записанными данными. А при превышении ограничений по времени или размеру старые файлы будут стираться.
Теперь, если мы захотим посмотреть на поведение JVM в какой-то момент времени, можно открыть соответствующий файл в JMC. Однако это не слишком удобно, т.к. нас может интересовать отрезок времени, не совпадающий с границами записи в файлах. Для решения этой проблемы мы можем выгрузить именно интересующий нас фрагмент записи:
В результате получим вывод:
Таким образом мы сохранили в файл данные за последние 10 минут. При этом сама запись не остановилась, и, если с приложением произойдёт ещё что-то интересное, мы сможем вытащить информацию за этот промежуток времени и проанализировать, что же с приложением случилось, во всех деталях.
Заключение
В данной статье мы рассмотрели, как можно управлять записью Java Flight Recorder, и актуальный набор параметров для этого.
За скобками осталось ещё очень много интересного, т. к. управлять записью можно ещё и программно. А также добавлять свои типы событий и метрик, а потом анализировать всю собранную информацию в Java Mission Control.
Но это всё уже темы для других статей.
А тем, кого интересует, как использовать JFR для анализа и оптимизации приложения, я рекомендую серию статей от Алексея Рагозина:
Мониторинг приложений Java с помощью Flight Recorder
1. Обзор
В этом руководстве мы рассмотрим Java Flight Recorder, его концепции, основные команды и способы его использования.
2. Утилиты мониторинга Java
3. Java Flight Recorder и его основные концепции
Чтобы использовать JFR, мы должны его активировать. Этого можно добиться двумя способами:
У JFR нет отдельного инструмента. Мы используем Java Mission Control (JMC), который содержит плагин, который позволяет нам визуализировать данные, собранные JFR.
JFR имеет две основные концепции: события и поток данных. Кратко обсудим их.
3.1. События
JFR собирает события, которые происходят в JVM при запуске приложения Java. Эти события связаны с состоянием самой JVM или состоянием программы. У события есть имя, отметка времени и дополнительная информация (например, информация о потоке, стек выполнения и состояние кучи).
3.2. Поток данных
События, которые собирает JFR, содержат огромное количество данных. По этой причине JFR по своей конструкции достаточно быстр, чтобы не мешать программе.
JFR сохраняет данные о событиях в одном выходном файле flight.jfr.
Как известно, дисковые операции ввода-вывода довольно дороги. Следовательно, JFR использует различные буферы для хранения собранных данных перед сбросом блоков данных на диск. Все может стать немного сложнее, потому что в один и тот же момент программа может иметь несколько процессов регистрации с разными параметрами.
В некоторых редких случаях JFR может не сбросить данные (например, при слишком большом количестве событий или в случае отключения электроэнергии). Если это происходит, JFR пытается сообщить нам, что в выходном файле может отсутствовать часть данных.
4. Как использовать Java Flight Recorder
Как мы уже упоминали выше, есть два способа активировать JFR. Когда мы активируем его одновременно с запуском приложения, мы делаем это из командной строки. Когда приложение уже запущено, мы используем диагностический командный инструмент.
4.1. Командная строка
После успешной компиляции мы можем запустить программу со следующими параметрами:
This command launches the application and activates the recording, which starts immediately and lasts no more than 200 seconds. Collected data is saved in an output file, flight.jfr. We’ll describe the other options in more detail in the next section.
4.2. Diagnostic Command Tool
We can also start registering the events by using the jcmd tool. For example:
Prior to JDK 11, in order to be able to activate JFR in this way, we should start the application with unlocked commercial features:
Once the application is running, we use its process id in order to execute various commands, which take the following format:
Here’s a complete list of the diagnostic commands:
Each command has a series of parameters. For example, the JFR.start command has the following parameters:
We’ve already seen an example of the usage of these parameters at the beginning of this section. For the complete list of the parameters, we may always consult the Java Flight Recorded official documentation.
Although JFR is designed to have as little of a footprint as possible on the performance of the JVM and the application, it’s better to limit the maximum amount of collected data by setting at least one of the parameters: duration, maxage, or maxsize.
5. Java Flight Recorder in Action
Let’s now demonstrate JFR in action by using an example program.
5.1. Example Program
Our program inserts objects into a list until an OutOfMemoryError occurs. Then the program sleeps for one second:
Without executing this code, we can spot a potential drawback: the while loop will lead to high CPU and memory usage. Let’s use JFR to see these drawbacks and probably find others.
5.2. Start Registering
First, we compile our program by executing the following command from the command line:
At this point, we should find a file FlightRecorder.class in the out/com/baeldung/flightrecorder directory.
Now, we’ll start the program with the following options:
5.3. Visualize Data
Now, we feed the file flight.jfr to Java Mission Control, which is part of the JDK distribution. It helps us visualize the data about our events in a nice and intuitive way.
Its main screen shows us the information about how the program was using the CPU during its execution. We see that the CPU was loaded heavily, which is quite expected due to the while loop:
On the left side of the view, we see sections General, Memory, Code, and Threads, among others. Each section contains various tabs with detailed information. For example, tab Hot Methods of section Code contains the statistics of method calls:
In this tab, we can spot another drawback of our example program: method java.util.ArrayList.grow(int) has been called 17 times in order to enlarge the array capacity every time there wasn’t enough space for adding an object.
In more realistic programs, we may see a lot of other useful information:
6. Conclusion
In this article, we introduced the topic of monitoring and profiling a Java application using Java Flight Recorder. This tool remains an experimental one, so we should consult its official site for more complete and recent information.
Как всегда, фрагмент кода доступен в нашем репозитории Github.
