В чём разница между Heap и Stack

Каждый вызов метода создает в стеке потока изолированный Stack Frame. Размер фрейма рассчитывается компилятором javac заранее на этапе компиляции и фиксируется в заголовке метод...

🟢 Junior Level

Heap (Куча) и Stack (Стек вызовов) — это две принципиально разные области оперативной памяти, выделяемые операционной системой для работы виртуальной машины Java (JVM). Их разделение продиктовано разными задачами: управление жизненным циклом выполнения кода (потоки и методы) и хранение данных (состояние объектов).

Бытовая аналогия

Stack (Рабочий стол): Небольшой персональный стол инженера. На нем лежат только те инструменты и чертежи, с которыми он работает прямо сейчас над текущей операцией. Когда деталь готова, рабочий стол мгновенно смахивается начисто. Места мало, но всё под рукой.
Heap (Центральный склад): Огромный общий склад предприятия. На нем хранятся готовые станки, материалы и контейнеры. Доступ к нему имеют все рабочие фабрики, поиск нужного ящика требует времени, а уборкой заброшенных материалов занимается специальная служба клининга (Garbage Collector).

Сравнительная таблица базовых характеристик

Характеристика	Stack (Стек)	Heap (Куча)
Что хранится?	Примитивные локальные переменные, ссылки на объекты, фреймы вызова методов	Все экземпляры классов (`new`), массивы, строки
Область видимости	Приватная для каждого потока (Thread-Safe)	Общая для всех потоков приложения (Shared Memory)
Размер памяти	Небольшой (по умолчанию 1 МБ на поток)	Большой (гигабайты, задается параметрами JVM)
Управление памятью	Аппаратное по принципу LIFO (мгновенно при выходе из метода)	Сборщик мусора (Garbage Collector) с паузами Stop-The-World
Критическая ошибка	`java.lang.StackOverflowError`	`java.lang.OutOfMemoryError: Java heap space`

Наглядный пример распределения памяти

public class MemoryDemo {
    public static void main(String[] args) {
        int age = 25;                  // Примитив -> хранится в Stack фрейма main
        String role = "Engineer";      // Ссылка role в Stack -> строка "Engineer" в String Pool (Heap)
        User user = new User("Alice"); // Ссылка user в Stack -> объект new User() в Heap
        
        calculate(age);                // Создается новый стек-фрейм для calculate()
    }

    private static void calculate(int value) {
        int result = value * 2;        // result и value живут в стек-фрейме calculate()
    }                                  // Фрейм calculate() уничтожается, память Stack освобождена
}

🟡 Middle Level

Внутреннее устройство стекового фрейма (Stack Frame)

Каждый вызов метода создает в стеке потока изолированный Stack Frame. Размер фрейма рассчитывается компилятором javac заранее на этапе компиляции и фиксируется в заголовке метода в байткоде:

┌────────────────────────────────────────────────────────┐
│                      STACK FRAME                       │
├────────────────────────────────────────────────────────┤
│ 1. Local Variable Table (Таблица локальных переменных) │
│    [0] = this (для нестатических методов)              │
│    [1] = param1, [2] = local_var                      │
├────────────────────────────────────────────────────────┤
│ 2. Operand Stack (Стек операндов для инструкций JVM)   │
│    iload_1, iload_2, iadd, istore_3                    │
├────────────────────────────────────────────────────────┤
│ 3. Frame Data (Служебные данные фрейма)                │
│    - Dynamic Linking (ссылки на Runtime Constant Pool) │
│    - Normal Method Completion (адрес возврата в метод) │
│    - Exception Dispatch Reference (таблица catch/try)  │
└────────────────────────────────────────────────────────┘

Параметр JVM: -Xss (например, -Xss1m). Увеличение -Xss позволяет выдерживать более глубокую рекурсию, но уменьшает максимальное количество потоков ОС, которое может создать процесс.

Аллокация в Heap: TLAB и Bump-the-pointer

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

Для решения этой проблемы HotSpot JVM использует TLAB (Thread Local Allocation Buffer):

При старте каждому потоку нарезается небольшой персональный буфер внутри региона Eden (обычно десятки-сотни килобайт).
Аллокация объекта в TLAB происходит через механизм Bump-the-pointer: указатель свободного места просто сдвигается на размер объекта (pointer += size).
Операция выполняется без атомарных инструкций (CAS) и блокировок, что делает аллокацию в Java быстрее, чем системный вызов malloc() в C++.
Если объект превышает свободный объем TLAB, поток запрашивает новый TLAB через атомарную операцию CAS, либо аллоцирует тяжелый объект напрямую в общую область Eden/Old Gen.

Оптимизации JIT: Escape Analysis и Scalar Replacement

HotSpot JIT-компилятор (C2) анализирует область видимости ссылок на создаваемые объекты с помощью механизма Escape Analysis (Анализ побега):

GlobalEscape: Ссылка на объект покидает метод (возвращается через return, сохраняется в статическое поле или поле другого долгоживущего объекта). Объект обязан жить в Heap.
ArgEscape: Ссылка передается в аргументы другого метода, но не сохраняется там.
NoEscape: Объект создается, используется и перестает существовать строго внутри одного метода.

Если объект имеет статус NoEscape, JIT применяет оптимизацию Scalar Replacement (Скалярная замена):

Объект не аллоцируется в куче вовсе и даже не создается как цельная структура данных!
Его поля «разваливаются» на отдельные скалярные примитивы и размещаются напрямую в регистрах процессора или в стековом фрейме.
Дополнительно применяется Lock Elision (Устранение блокировок): если на объекте вызывается synchronized, блокировка полностью вырезается JIT-ом, так как объект гарантированно недоступен другим потокам.

public void processCoordinates() {
    Point point = new Point(10, 20); // NoEscape: ссылка не покидает метод
    int sum = point.x + point.y;
    // C2 разложит Point на int point_x = 10; int point_y = 20; 
    // Нагрузка на GC равна НУЛЮ!
}

🔴 Senior Level

Compressed OOPs и барьер 32 ГБ памяти

В 64-битных системах указатели на объекты (OOP — Ordinary Object Pointers) имеют размер 8 байт (64 бита). Это увеличивает размер кучи на 30–40% и резко снижает эффективность кэшей процессора L1/L2/L3 (Cache Misses).

Для решения этой проблемы в 64-битной JVM HotSpot применяется технология Compressed OOPs (-XX:+UseCompressedOops):

Поскольку все объекты в Java выравниваются по границе 8 байт (младшие 3 бита адреса всегда равны 000), JVM отбрасывает эти 3 нуля при хранении адреса в памяти.
При загрузке адреса в регистр CPU выполняется побитовый сдвиг влево на 3 бита (address << 3), восстанавливая исходный 64-битный адрес.
Это позволяет адресовать 32-битным числом объем памяти: $2^{32} \times 8 \text{ байт} = 32 \text{ ГБ}$.

Heap < 32 GB: Ссылки занимают 4 байта (Compressed OOPs активны)
Heap > 32 GB: Ссылки занимают 8 байт (Compressed OOPs отключаются)

⚠️ Highload Gotcha: Куча с -Xmx31g вмещает больше полезных данных и работает на 15–20% быстрее, чем куча с -Xmx33g. При переходе за 32 ГБ размер всех указателей удваивается, мгновенно съедая лишние 2–4 ГБ памяти и снижая пропускную способность шины памяти.

Анатомия объекта в памяти (Object Layout)

Каждый объект в Heap состоит из служебного заголовка и полезных данных:

┌────────────────────────────────────────────────────────┐
│                   OBJECT HEADER                        │
├────────────────────────────────────────────────────────┤
│ 1. Mark Word (8 байт на 64-бит JVM)                    │
│    - HashCode объекта (лениво вычисляемый identity)    │
│    - Age bits (4 бита: возраст объекта от 0 до 15)     │
│    - Biased Locking / Lock status (состояние блокировок)│
│    - GC tagging bits                                   │
├────────────────────────────────────────────────────────┤
│ 2. Klass Word (4 байта при Compressed Class Pointers)  │
│    - Ссылка на метаданные класса в Metaspace           │
├────────────────────────────────────────────────────────┤
│ 3. Array Length (4 байта, только для массивов)         │
├────────────────────────────────────────────────────────┤
│ 4. Instance Data (значения полей объекта)              │
│    - Поля переупорядочиваются JVM для минимизации gap  │
├────────────────────────────────────────────────────────┤
│ 5. Padding (Выравнивание)                              │
│    - Добивка нулями до размера, кратного 8 байтам      │
└────────────────────────────────────────────────────────┘

Пустой объект new Object() занимает ровно 16 байт памяти (8 байт Mark Word + 4 байта Klass Pointer + 4 байта padding).

Архитектура NUMA (Non-Uniform Memory Access)

На многосокетных серверах оперативная память привязана к конкретным физическим процессорам (NUMA-нодам). Доступ ядра CPU к локальной памяти происходит в 2–3 раза быстрее, чем к памяти, подключенной к соседнему сокету через шину QPI/UPI.

Флаг -XX:+UseNUMA заставляет JVM нарезать регионы кучи (Eden) с учетом топологии NUMA.
Потоки, исполняемые на Socket 0, получают TLAB в памяти Socket 0, устраняя межсокетный трафик шины и снижая задержки аллокации.

Project Loom: Стек виртуальных потоков (Java 21+)

Классический платформенный поток Java (java.lang.Thread) обернут вокруг нативного потока ОС (pthread) со статическим стеком 1 МБ. Создание 10 000 потоков требует 10 ГБ физической памяти только на стеки.

Virtual Threads (Виртуальные потоки):

Не имеют постоянного выделенного стека ОС.
Их стек-фреймы хранятся в Heap в виде объектов Continuation.
При блокировке (например, чтение из сокета или Thread.sleep()) виртуальный поток отмонтируется (unmount) от несущего потока (Carrier Thread), а его стек сериализуется в кучу (начиная всего с нескольких сотен байт).
При возобновлении задачи стек восстанавливается (mount) на любой свободный Carrier Thread. Это позволяет запускать миллионы конкурентных потоков в едином процессе.

🎯 Шпаргалка для интервью

30-секундный ответ (Elevator Pitch)

«Stack — это приватная для каждого потока область памяти с быстрым LIFO-доступом, где хранятся стековые фреймы вызовов методов, локальные примитивы и ссылки на объекты. Он очищается аппаратно и мгновенно при выходе из метода, а переполнение ведет к StackOverflowError. Heap — общая для всех потоков память, где хранятся экземпляры объектов, массивы и строковый пул. Куча управляется Garbage Collector, а аллокация в ней оптимизирована с помощью потокобезопасных буферов TLAB (bump-the-pointer). Благодаря анализу побега (Escape Analysis) JIT-компилятор может разложить короткоживущие объекты на примитивы на стеке (Scalar Replacement). Важнейший порог в production — 32 ГБ кучи, выше которого отключаются Compressed OOPs, снижая производительность».

3–4 каверзных вопроса с ответами

Может ли объект в Java создаваться на стеке, а не в куче?
- Ответ: Спецификация JVM формально требует, чтобы все объекты создавались в Heap. Однако в современных реализациях (HotSpot JVM) благодаря Escape Analysis компилятор C2 выполняет Scalar Replacement: если объект не «убегает» за пределы метода, сам объект не инстанцируется вовсе, а его поля размещаются как скалярные переменные в стековом фрейме или регистрах CPU. Это дает тот же эффект, что и stack allocation, не требуя нагрузки на GC.
Почему куча размером 31 ГБ часто работает эффективнее и быстрее, чем 33 ГБ?
- Ответ: При размере кучи до 32 ГБ JVM включает Compressed OOPs (сжатые указатели), адресуя память с шагом в 8 байт и используя 4-байтные ссылки вместо 8-байтных. При превышении 32 ГБ JVM вынуждена перейти на полные 64-битные указатели. Из-за этого все ссылки в объектах и массивах удваиваются в объеме, занимая на 20–30% больше RAM и вымывая кэш-линии процессора L1/L2/L3. В итоге полезная емкость кучи 33 ГБ оказывается ниже, чем у 31 ГБ.
Где хранится стек виртуальных потоков (Virtual Threads) в Java 21+?
- Ответ: Стек виртуальных потоков хранится в куче (Heap) в виде чанков continuation-объектов. Виртуальный поток занимает в памяти от пары сотен байт до нескольких килобайт и динамически растет/сжимается. Только в момент непосредственного выполнения на процессоре его текущий фрейм монтируется на нативный стек несущего потока (Carrier Thread).
Что происходит, если поток пытается аллоцировать массив размером 50 МБ, поместится ли он в TLAB?
- Ответ: Нет, стандартный размер TLAB составляет от десятков до сотен килобайт. Для массивов и объектов, размер которых превышает лимит TLAB, JVM использует механизм прямой аллокации в общий регион Eden с синхронизацией, либо (в сборщике G1) аллоцирует его напрямую в категорию Humongous Regions (специальные непрерывные цепочки регионов для объектов размером $> 50\%$ от размера региона G1).

Типичные ошибки и Red Flags

🚩 Утверждение: «Garbage Collector очищает память как в Heap, так и в Stack» (грубейшая ошибка: память стека освобождается аппаратно при сдвиге Stack Pointer).
🚩 Заблуждение: «Объекты ВСЕГДА и БЕЗ ИСКЛЮЧЕНИЙ создаются в Heap» (демонстрирует незнание Escape Analysis и Scalar Replacement).
🚩 Установка -Xmx34g на production-серверах без обоснования (демонстрирует непонимание барьера Compressed OOPs в 32 ГБ).
🚩 Представление о примитивах как «всегда живущих на стеке» (примитивные поля внутри объектов new User() живут вместе с объектом в Heap).

Связанные темы

Что хранится в Heap — детальная структура регионов кучи
Что хранится в Stack — подробный разбор содержимого стек-фрейма
Что такое Garbage Collection — алгоритмы сборки мусора в куче
Что такое поколения в GC — Eden, Survivor, Tenured, Metaspace
Что такое параметры -Xms и -Xmx — сайзинг кучи в production