Архитектура JVM в Java

Виртуальная машина Java — это программа, которая запускает вашу программу. Вы компилируете исходный код .java в платформонезависимый байт-код .class, а JVM — это то, что загружает этот байт-код, верифицирует его, размещает его объекты в памяти и исполняет его на реальном оборудовании. «Write once, run anywhere» на самом деле означает «скомпилируй один раз, а остальное пусть делает JVM каждой платформы». Эта глава картирует внутреннюю структуру JVM — три подсистемы, общие для каждой реализации, — чтобы у следующих глав о памяти и сборке мусора был каркас, на который можно опереться.

Три подсистемы

JVM, от какого бы поставщика она ни была, организована в три взаимодействующие подсистемы. Всё остальное — это детали внутри одной из них.

Подсистема	Ответственность
Загрузчик классов	Находит, загружает, связывает и инициализирует файлы `.class` в среде выполнения
Области данных времени выполнения	Память, которой управляет JVM: куча, стеки, область методов, регистры PC
Движок исполнения	Интерпретирует и JIT-компилирует байт-код и запускает сборщик мусора

Загрузчик классов вносит типы внутрь, области данных времени выполнения хранят состояние, а движок исполнения исполняет код. Вызов метода затрагивает все три: его класс загружается, его кадр кладётся на стек, а его байт-код исполняется.

Подсистема загрузчика классов

Не все классы загружаются при запуске. JVM загружает класс лениво, при первом обращении к нему, в три фазы: загрузка (чтение байтов), связывание (верификация байт-кода, подготовка статических полей, разрешение ссылок) и инициализация (выполнение статических инициализаторов и блоков static { }).

Загрузчики образуют иерархию «сначала родитель». Когда у загрузчика запрашивают класс, он делегирует вверх своему родителю, прежде чем попробовать сам — так что базовый тип вроде String всегда поступает от доверенного загрузчика bootstrap и никогда не может быть затенён кодом приложения.

// Пройти по цепочке загрузчиков любого класса
ClassLoader loader = MyType.class.getClassLoader();
while (loader != null) {
  System.out.println(loader.getName());
  loader = loader.getParent();
}
// Результат null означает загрузчик bootstrap (нативный, без Java-объекта).
System.out.println(String.class.getClassLoader()); // печатает: null

Три стандартных загрузчика, от потомка к родителю, — это загрузчик приложения (classpath), загрузчик платформы (модули JDK вроде java.sql) и загрузчик bootstrap (ядро java.base, реализованное в нативном коде, представленное как null).

Области данных времени выполнения

После загрузки класса его код и данные живут в областях, которые JVM разбивает для разных целей:

Куча (heap) — разделяется между всеми потоками; здесь живут каждый объект и каждый массив. Это то, чем управляет сборщик мусора.
Стеки JVM — по одному на поток. Каждый вызов метода кладёт кадр, содержащий локальные переменные и операнды; кадр снимается при возврате. Глубокая рекурсия переполняет его (StackOverflowError).
Область методов (Metaspace в современных JVM) — метаданные классов, пул констант времени выполнения и статические поля. Память вне кучи.
Регистр PC — на поток; адрес исполняемой в данный момент инструкции байт-кода.

// Аллокация в куче: 'new' вырезает место из кучи
byte[] buffer = new byte[1024]; // живёт в куче, под управлением GC

// Рост стека: каждый вызов добавляет кадр в стек этого потока
static long factorial(long n) {
  return n <= 1 ? 1 : n * factorial(n - 1); // каждый вызов = ещё один кадр
}

Куча против не-кучи — ключевое разделение: экземпляры объектов находятся в куче; структуры классов и сама машинерия — нет.

Движок исполнения

Движок исполнения превращает байт-код в действие. Современные JVM HotSpot адаптивны: они начинают с интерпретации байт-кода (быстрый старт), профилируют, какие методы исполняются горячо, затем передают их компилятору Just-In-Time (JIT), который выдаёт оптимизированный нативный машинный код. Холодный код остаётся интерпретируемым; горячий код компилируется — вы платите за оптимизацию только там, где она окупается.

В движке также размещаются сборщик мусора, который освобождает объекты кучи, более не достижимые ни по одной живой ссылке, и Java Native Interface (JNI) — мост к библиотекам, написанным на C/C++.

// Горячий цикл: JIT скомпилирует sum() в нативный код после достаточного числа вызовов
long total = 0;
for (int i = 0; i < 100_000_000; i++) {
  total += i; // сначала интерпретируется, затем JIT-компилируется, затем намного быстрее
}

Проработанный пример: инспекция живой JVM

Эта программа ничего не настраивает — она просит работающую JVM описать себя через бины java.lang.management и API загрузчика классов. Она называет VM и движок исполнения, проходит по иерархии загрузчиков, сообщает память кучи против не-кучи и наращивает стек рекурсией.

java— editable, runs on the server

import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;
import java.lang.management.MemoryUsage;
import java.lang.management.RuntimeMXBean;

public class JvmArchitectureDemo {
  public static void main(String[] args) {
    // 1. The execution engine reports who is running the bytecode.
    RuntimeMXBean runtime = ManagementFactory.getRuntimeMXBean();
    System.out.println("vm name    : " + runtime.getVmName());
    System.out.println("vm vendor  : " + runtime.getVmVendor());
    System.out.println("spec ver   : " + System.getProperty("java.specification.version"));

// 2. Walk the class loader chain from this class up to the bootstrap loader.
    System.out.print("loader chain: ");
    ClassLoader cl = JvmArchitectureDemo.class.getClassLoader();
    while (cl != null) {
      String name = cl.getName();
      System.out.print((name == null ? "<unnamed>" : name) + " -> ");
      cl = cl.getParent();
    }
    // A null parent at the top is the bootstrap loader (native, no Java object).
    System.out.println("bootstrap(null)");

// Core JDK classes always come from the bootstrap loader.
    System.out.println("String via : " + String.class.getClassLoader());

// 3. Runtime data areas: the JVM splits memory into heap and non-heap.
    MemoryMXBean memory = ManagementFactory.getMemoryMXBean();
    MemoryUsage heap = memory.getHeapMemoryUsage();
    MemoryUsage nonHeap = memory.getNonHeapMemoryUsage();
    System.out.println("heap used  : " + (heap.getUsed() / 1024) + " KB");
    System.out.println("heap max   : " + (heap.getMax() / (1024 * 1024)) + " MB");
    System.out.println("nonheap use: " + (nonHeap.getUsed() / 1024) + " KB");

// 4. The stack: each thread gets its own frames. Recursion grows it.
    System.out.println("stack depth: " + depth(1));
  }

// Each call pushes a new frame onto this thread's JVM stack.
  static int depth(int n) {
    if (n >= 5) return n;
    return depth(n + 1);
  }
}

Что вынести из запуска:

RuntimeMXBean называет движок исполнения — VM семейства HotSpot (строка vm name показывает что-то вроде «OpenJDK 64-Bit Server VM») — подтверждая, что ваш байт-код исполняет JIT-способный движок «Server», а не голый интерпретатор.
Цепочка загрузчиков печатает что-то вроде <unnamed> -> app -> platform -> bootstrap(null): каждый шаг цикла поднимался к родителю, и цепочка завершилась null-родителем — загрузчиком bootstrap, который является нативным кодом без Java-объекта. Иерархия реальна и наблюдаема, а не метафора.
String.class.getClassLoader() равно null — базовые типы java.base поступают от того же загрузчика bootstrap на вершине цепочки, и именно поэтому код приложения никогда не может подменить собственную String. Делегирование «сначала родитель» делает своё дело.
Строки памяти показывают использованную кучу в КБ, но максимум кучи в МБ, а также отдельную цифру не-кучи: экземпляры объектов живут в управляемой GC куче, тогда как метаданные классов (Metaspace) учитываются как не-куча — две области отслеживаются независимо.
depth(1) возвращает 5, потому что каждый рекурсивный вызов положил собственный кадр на стек JVM этого потока и снял его при возврате; стек существует на поток и структурирован кадрами, поэтому неуправляемая рекурсия заканчивается StackOverflowError, а не порчей кучи.

Практика

Программа Java ссылается на класс 'java.lang.String'. В стандартной иерархии загрузчиков «сначала родитель» какой загрузчик в конечном счёте предоставляет его и как этот загрузчик выглядит из кода Java?

Его предоставляет загрузчик bootstrap, и он выглядит как 'null', потому что загрузчик bootstrap — это нативный код без Java-объекта
Его предоставляет загрузчик приложения (classpath), и он выглядит как объект с именем 'app'
Его предоставляет загрузчик платформы, и он выглядит как объект с именем 'platform'
Его предоставляет тот загрузчик, который запросил класс, поскольку загрузчики пробуют сами, прежде чем делегировать родителю