Что происходит внутри JVM: память, сборка мусора и компиляция

Когда разработчик пишет Java-код, обычно не задумывается о том, что происходит после нажатия кнопки Run. Код компилируется, приложение запускается, и всё работает. Но между исходниками и выполнением программы находится сложный слой, Java Virtual Machine (JVM).

JVM — это не просто среда запуска Java. Это полноценная платформа исполнения, которая управляет памятью, оптимизирует код во время выполнения и автоматически очищает неиспользуемые объекты. Именно благодаря JVM Java может сохранять баланс между переносимостью, безопасностью и производительностью.
Фактически JVM берёт на себя множество задач, которые в других языках лежат на плечах разработчика. Например, ручное управление памятью или оптимизацию машинного кода.

Если упростить, то большинство внутренних процессов JVM можно свести к трём ключевым системам:

• Java Memory Model — правила работы с памятью и потоками

• Garbage Collection — автоматическое управление памятью

• JIT Compilation — динамическая компиляция байткода в машинный код

Понимание этих механизмов особенно полезно, когда возникают проблемы с производительностью, памятью или многопоточностью.

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

Процесс выглядит примерно так:

1. Исходный .java файл компилируется компилятором javac
2. Получается .class файл с байткодом
3. JVM загружает классы через ClassLoader
4. Байткод проходит проверку безопасности
5. Код интерпретируется или компилируется JIT-компилятором

Байткод — это универсальный набор инструкций, понятный JVM. Благодаря этому один и тот же .class файл может выполняться на Windows, Linux или macOS.
Но JVM не просто выполняет байткод. Она постоянно анализирует программу и оптимизирует её поведение во время работы.

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

Основные области памяти JVM:

• Heap — хранение объектов
• Stack — вызовы методов и локальные переменные
• Metaspace — метаданные классов
• PC Register — указатель текущей инструкции
• Native Method Stack — выполнение native-кода

На практике разработчики чаще всего сталкиваются с двумя областями: stack и heap.


Stack: память вызовов методов

Каждый поток в JVM имеет собственный стек. Когда вызывается метод, создаётся stack frame — специальная структура, содержащая параметры метода, локальные переменные, промежуточные значения вычислений, адрес возврата.

Рассмотрим простой пример:

Во время выполнения стек будет выглядеть примерно так:

Когда метод bar() завершится, его frame просто удалится со стека. Благодаря такой структуре стек работает очень быстро: память выделяется и освобождается по принципу LIFO (last in, first out).


Heap: где живут объекты

Heap — это общая область памяти, где размещаются объекты приложения, а также String Pool.

Например:

В этом случае:

• переменная user находится в stack
• сам объект User размещается в heap

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

Когда в программе появляется несколько потоков, ситуация становится сложнее. Здесь начинает работать Java Memory Model (JMM).

JMM определяет:

• Как изменения памяти становятся видимыми другим потокам
• В каком порядке могут выполняться инструкции
• Какие гарантии дают механизмы синхронизации

На уровне процессора инструкции могут переупорядочиваться ради оптимизации. Это называется instruction reordering.

Например, рассмотрим код:

Логически кажется, что если ready == true, то number уже должен быть равен 42. Но без синхронизации JVM или процессор могут изменить порядок операций.

Чтобы избежать подобных ситуаций, используются механизмы синхронизации: volatile, synchronized, Lock, классы из java.util.concurrent.atomic.
Эти механизмы создают happens-before отношения, которые гарантируют корректную видимость изменений между потоками.

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

Сборщик мусора работает по следующему принципу:

Определяется набор GC roots —> выполняется обход всех достижимых объектов —> объекты без ссылок считаются мусором —> их память освобождается

К GC roots относятся:

• Локальные переменные в стеке
• Активные потоки
• Статические поля
• Ссылки из native-кода

Если объект невозможно достичь из этих точек, он считается неиспользуемым.

Практика показывает, что большинство объектов в приложениях живёт очень недолго. Например, временные строки, DTO-объекты или структуры запроса.

Чтобы использовать эту особенность, heap делится на несколько областей:

• Young Generation — новые объекты

• Old Generation — долгоживущие объекты

• Metaspace — метаданные классов

Когда объект создаётся, он сначала попадает в Young Generation. Если он переживает несколько сборок мусора, JVM перемещает его в Old Generation.
Это позволяет чаще очищать маленькую область молодых объектов и реже выполнять более дорогую очистку всей памяти.

Типы сборок мусора обычно делятся на:

• Minor GC — очистка молодого поколения

• Major GC — очистка старого поколения

• Full GC — очистка всего heap

Minor GC происходит часто и обычно быстро, тогда как Full GC может приводить к заметным паузам.

За годы развития JVM появилось несколько алгоритмов сборки мусора. Они отличаются стратегией очистки памяти и длительностью пауз.

Сегодня чаще всего используются:

• G1 GC — стандартный GC в современных JVM

• ZGC — сборщик с очень низкими паузами

• Shenandoah — параллельная сборка мусора

• Parallel GC — оптимизирован для throughput

Например, G1 GC делит heap на множество небольших регионов и очищает их постепенно, чтобы уменьшить паузы выполнения.

Когда JVM только запускает программу, байткод обычно выполняется интерпретатором. Но интерпретация медленнее машинного кода.

Поэтому JVM использует JIT-компиляцию (Just-In-Time).
JIT анализирует выполнение программы и компилирует часто используемые участки кода в машинные инструкции. Такие участки называют горячим кодом (hot code). Это позволяет постепенно ускорять приложение по мере его работы.

При этом в последние годы в экосистеме Java развивается и альтернативный подход — AOT-компиляция (Ahead-Of-Time). Например, GraalVM позволяет компилировать приложение в нативный бинарник заранее, ещё до запуска.

Если JIT делает ставку на динамическую оптимизацию во время выполнения, то AOT — на быстрый старт и предсказуемое потребление ресурсов. В итоге оба подхода сегодня сосуществуют и используются в разных сценариях.

JIT-компилятор применяет множество оптимизаций, чтобы ускорить выполнение программы.

Среди наиболее распространённых:

• Inlining — вставка кода метода прямо в вызывающий код

• Dead Code Elimination — удаление неиспользуемого кода

• Loop Unrolling — оптимизация циклов

• Escape Analysis — анализ необходимости размещения объекта в heap

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

Во многих проектах можно долго писать код и почти не думать о внутреннем устройстве JVM. Но в некоторых ситуациях эти знания становятся критически важными.

Чаще всего разработчики обращаются к внутренностям JVM, когда сталкиваются с проблемами производительности, частыми GC-паузами, утечками памяти, сложными багами многопоточности, настройкой JVM для высоконагруженных сервисов.

Например, если сервис регулярно попадает в Full GC, это может означать неправильный размер heap или наличие долгоживущих объектов, которые не освобождаются.

JVM — это сложная система, которая скрывает от разработчика множество низкоуровневых деталей. Она управляет памятью, оптимизирует выполнение кода и автоматически освобождает ресурсы.
Под капотом Java-приложения постоянно происходят процессы: создаются и удаляются объекты, анализируется поведение программы, компилируется горячий код. Всё это позволяет Java оставаться одной из самых стабильных и производительных платформ разработки.

Понимание Java Memory Model, Garbage Collection и JIT-компиляции помогает лучше объяснить поведение приложений и быстрее находить проблемы, которые не видны на уровне исходного кода.


Хотите узнать больше? Изучите другие статьи из раздела:

• Java