Моніторинг JVM: JMX, VisualVM, Java Flight Recorder

1. JMX (Java Management Extensions): серце моніторингу JVM

Моніторинг — це як регулярний медогляд для вашого застосунку. Якщо логування можна порівняти з щоденником, куди записується все, що вже сталося, то моніторинг — це набір приладів, які показують стан системи прямо зараз: температуру, пульс, тиск, рівень цукру та інші життєво важливі показники JVM.

Він допомагає зрозуміти, скільки пам’яті реально використовується і чи немає витоків, скільки потоків працює і в якому вони стані — чекають, виконуються чи заблоковані. Можна побачити, як часто спрацьовує збирач сміття, наскільки завантажений процесор та вчасно помітити тривожні симптоми на кшталт раптового зростання пам’яті або кількості потоків.

Якщо коротко, логування розповідає, що вже відбулося, а моніторинг показує, що відбувається прямо зараз.

Основи JMX: що це і навіщо

JMX — це технологія в Java, яка дозволяє спостерігати за життям вашого застосунку зсередини і навіть трохи керувати ним. Вона працює через спеціальні об’єкти — MBean (Management Bean). Можна сказати, це як «датчики» та «тумблери» всередині JVM: одні показують стан системи, інші дозволяють щось підкрутити.

За допомогою JMX ви можете дізнатися, скільки пам’яті зараз виділено у JVM, скільки потоків активні, скільки часу йде на збірку сміття та багато іншого — без необхідності лізти в код або перезапускати застосунок.

Як це влаштовано

У JVM «з коробки» вже є безліч MBean-ів, які дають інформацію про:

• пам’ять (heap, non-heap);
• збирачі сміття (GC);
• потоки;
• класи (скільки завантажено, вивантажено);
• і навіть про саму JVM (версія, параметри запуску).

JMX — це як панель приладів в автомобілі. Ви бачите швидкість, оберти, температуру двигуна — і все це доступно через стандартні датчики (MBean-и).

Як отримати доступ до JMX

Найпростіший спосіб — використати стандартну утиліту JConsole, яка входить до JDK.

Запуск JConsole

1. Відкрийте термінал/командний рядок.
2. Виконайте команду:

   jconsole
   

3. Виберіть процес Java, який хочете моніторити (наприклад, свій застосунок).

JConsole підключиться до JVM через JMX і покаже графіки та таблиці: використання пам’яті, кількість потоків, активність збирача сміття тощо.

Приклад: переглянути пам’ять і потоки

У JConsole відкрийте вкладки «Memory» та «Threads». Ви побачите, як змінюється обсяг використаної пам’яті, скільки потоків зараз працює, які з них активні, а які очікують.

Власні MBean-и

Можна створювати свої MBean-и для моніторингу власних метрик (наприклад, кількості оброблених замовлень). Але це вже тема для просунутих: стандартні MBean-и дають дуже багато інформації.

2. VisualVM — візуальний моніторинг і профілювання

Якщо JConsole — це «приладова панель», то VisualVM — це цілий діагностичний центр із рентгеном, МРТ та аналізом крові. Він дозволяє не лише моніторити, а й профілювати застосунок, знімати heap dump, аналізувати витоки й бачити, які методи займають найбільше часу.

Встановлення та запуск VisualVM

• VisualVM входить до складу JDK (зазвичай як jvisualvm), але свіжу версію можна завантажити на visualvm.github.io.
• Запускається командою:

  jvisualvm
  

• Після запуску ви побачите список усіх Java-процесів, запущених на вашій машині.

Підключення до процесу

1. Знайдіть свій процес (наприклад, Main або MyApp) у списку.
2. Двічі клацніть по ньому — відкриється вкладка з інформацією про процес.
3. Готово! Тепер ви бачите:
   • Використання CPU і пам’яті в реальному часі.
   • Кількість потоків і їхній стан.
   • Список завантажених класів.
   • Можливість зняти heap dump і thread dump.

Основні можливості VisualVM

З VisualVM можна спостерігати, як використовується пам’ять — і heap, і non-heap. На графіку видно, чи зростає споживання або стабілізується. Щоб перевірити роботу збирача сміття, натисніть кнопку «Perform GC» — JVM одразу спробує очистити пам’ять. Можна зробити heap dump (знімок пам’яті) і вивчити його для пошуку витоків.

Інструмент покаже й стан потоків: скільки їх запущено, які працюють, очікують або заблоковані. Якщо стався deadlock, VisualVM допоможе його виявити й показати взаємоблокування.

Для глибокого аналізу є профілювання: ви побачите «гарячі» методи, які «їдять» найбільше процесорного часу або пам’яті. Це корисно під час діагностики неочікуваного падіння продуктивності.

Приклад: моніторимо міні-застосунок

public class MemoryLeakDemo {
    public static void main(String[] args) throws InterruptedException {
        List<byte[]> memoryConsumers = new ArrayList<>();
        for (int i = 0; i < 1000; i++) {
            memoryConsumers.add(new byte[1024 * 1024]); // 1 MB
            Thread.sleep(100); // Трохи зачекаємо, щоб графік був плавнішим
        }
        System.out.println("Готово! Не забудьте подивитися у VisualVM :)");
        Thread.sleep(60000); // Тримаємо застосунок відкритим для аналізу
    }
}

Тепер:

1. Запустіть програму.
2. Відкрийте VisualVM, підключіться до процесу.
3. Подивіться, як зростає використання пам’яті.
4. Зніміть heap dump, знайдіть масиви, що займають пам’ять.

3. Java Flight Recorder (JFR): чорний ящик для JVM

Що таке JFR

Java Flight Recorder — вбудований у JVM інструмент для збирання докладних подій про роботу застосунку. Це «чорний ящик»: JFR пише, що відбувається в JVM, щоб потім знайти вузькі місця або причини інциденту.

JFR збирає:

• події GC;
• інформацію про потоки;
• частоту виклику методів і профілі часу;
• паузи та затримки;
• винятки та помилки.

Як увімкнути JFR

Починаючи з Java 11+, JFR є прямо в OpenJDK.

Запуск із JFR

java -XX:StartFlightRecording=filename=recording.jfr,duration=60s,settings=profile -jar MyApp.jar

• filename=recording.jfr — куди зберегти запис.
• duration=60s — скільки писати.
• settings=profile — рівень деталізації (default, profile, continuous).

Перегляд результатів

Для аналізу файлу .jfr використовується JDK Mission Control (JMC):

1. Завантажте JMC: jdk.java.net/jmc
2. Відкрийте файл recording.jfr.
3. Вивчіть графіки, «гарячі» методи, паузи GC та активність потоків.

Приклад: знімаємо «чорний ящик»

1. Запустіть застосунок із JFR (див. команду вище).
2. Відкрийте JDK Mission Control, завантажте файл запису.
3. Оцініть «гарячі» місця за CPU/пам’яттю, частоту збірок сміття та кількість активних потоків.

4. Практика: моніторимо застосунок

import java.util.ArrayList;
import java.util.List;

public class MonitoringExample {
    public static void main(String[] args) throws InterruptedException {
        List<byte[]> memory = new ArrayList<>();
        for (int i = 0; i < 50; i++) {
            memory.add(new byte[2 * 1024 * 1024]); // 2 MB
            Thread.sleep(500);
        }
        // Запускаємо потік
        new Thread(() -> {
            while (true) {
                try {
                    Thread.sleep(1000);
                    System.out.println("Фоновий потік працює...");
                } catch (InterruptedException e) {
                    break;
                }
            }
        }).start();

        Thread.sleep(20000); // Тримаємо застосунок відкритим для моніторингу
    }
}

Дії:

• Запустіть програму.
• Відкрийте VisualVM, знайдіть процес, подивіться на графік пам’яті та потоки.
• Спробуйте зняти heap dump і thread dump.
• Для просунутих: запустіть із JFR і подивіться результати в JMC.

5. Корисні нюанси

Порівняльна таблиця інструментів моніторингу

jconsole

jvisualvm

java -XX:StartFlightRecording...

Рекомендації

• Моніторте не лише у продакшені, а й на етапі тестування. Так ви раніше спіймаєте витоки пам’яті та «завислі» потоки.
• Heap dump — не боляче! Знімайте дамп пам’яті при підозрі на витік і вивчайте його у VisualVM.
• Не бійтеся експериментувати з JFR. Навіть якщо не все зрозуміло одразу, події та графіки допоможуть знайти вузькі місця.
• JMX можна використовувати програмно. Наприклад, щоб надсилати метрики до Prometheus/Grafana.
• Профілювання — не для постійної роботи. Вмикайте профайлери точково, інакше застосунок може сповільнитися.

6. Типові помилки під час моніторингу JVM

Помилка № 1: Не моніторити взагалі. Багато новачків думають, що якщо застосунок «працює», то все гаразд. Насправді проблеми з пам’яттю і потоками часто проявляються під навантаженням або з часом. Не лінуйтеся відкривати VisualVM/JConsole хоча б періодично.

Помилка № 2: Знімати heap dump на великих застосунках без підготовки. Heap dump великого застосунку може важити гігабайти й «заморозити» процес на кілька секунд. Робіть це в тестовому середовищі або в «тихі» години, якщо йдеться про продакшн.

Помилка № 3: Ігнорувати показники GC і потоків. Постійно висока частка часу на GC — тривожний сигнал! А якщо кількість потоків стабільно зростає — шукайте витік потоків.

Помилка № 4: Не аналізувати результати моніторингу. Просто відкрити VisualVM — замало. Дивіться, які об’єкти займають пам’ять, які методи «їдять» CPU, чому з’являються deadlock-и. Розбирайте стек-трейси та причини.

Помилка № 5: Використовувати профайлери в продакшені без розуміння. Профілювання може значно сповільнити застосунок. Вмикайте його лише для діагностики, а не «на постійній основі».