JVM, память и GC на Java-собеседовании: вопросы с разбором

Серия подготовки: к обзору тем Java-собеседования.

Вопросы о JVM, памяти и сборке мусора в Java становятся понятнее, если проследить жизнь одной программы: как запускается код, где хранятся данные, почему часть объектов исчезает, а часть продолжает занимать память. Разберём 19 вопросов с этой точки зрения, затем перейдём к загрузке классов и поиску причин сбоев.

JVM, Java Virtual Machine, — виртуальная машина, которая выполняет подготовленные для неё инструкции. JDK — комплект разработки: в него входят средства запуска, компилятор и диагностические инструменты. Запущенное Java-приложение работает в процессе операционной системы и использует реальную память компьютера. «Виртуальная» здесь не означает, что память бесплатна или бесконечна.

Основа статьи — Java 17/21 и HotSpot, распространённая реализация JVM. Спецификация описывает обязательное поведение виртуальной машины; реализация выбирает, как его обеспечить. Это различие понадобится, когда будем говорить о физическом размещении объектов и оптимизациях. Все примеры учебные: они показывают механизм, а не результаты измерений производительности.

Как JVM выполняет код и размещает данные

1. Что происходит между javac и работающей программой?

Написанный файл .java содержит понятный человеку текст. Компилятор javac проверяет его по правилам языка и создаёт файлы .class. В них находятся байткод — инструкции для JVM — и сведения о классах, их полях и методах. Это ещё не тот машинный код, который процессор непосредственно исполняет.

При запуске JVM загружает нужные классы, проверяет допустимость байткода и выполняет инструкции. HotSpot может сначала исполнять код через интерпретатор, а часто используемые участки переводить в машинный код во время работы. Этим занимается JIT-компилятор: just-in-time означает компиляцию по ходу исполнения. Поэтому начало работы программы и её работа после множества запросов могут отличаться по скорости.

Подвох: новая версия class-файла не обязана поддерживаться старой JVM. Параметр javac --release помогает собрать код для целевого выпуска, учитывая его язык и доступный стандартный API — методы и классы библиотеки. Но он не проверяет за вас совместимость всех сторонних библиотек. Перед запуском нужно знать и версию сборки, и версию среды исполнения.

2. Какие области памяти описывает спецификация JVM?

Метод заказа вызывает метод расчёта, тот — метод округления. Пока последний работает, нужно помнить, куда вернуться и какие значения остались у предыдущих вызовов. Для этого поток исполнения, то есть отдельная последовательность работы программы, имеет стек JVM. При вызове метода появляется кадр с локальными значениями и промежуточными результатами; при завершении вызова он убирается. Счётчик инструкции помогает отслеживать текущий шаг.

Heap, или куча, — общая область для объектов и массивов в модели JVM. Один объект могут использовать несколько потоков. Method area хранит сведения о классах: их полях, методах и нужных константах. Runtime constant pool — часть этих сведений, включающая константы и ссылки на используемые классы, методы и поля. Спецификация также предусматривает стеки для native-методов, выполняемых вне Java.

Это описание назначения данных, а не обязательная карта физических адресов. Например, спецификация допускает разное размещение кадров стека. Термин metaspace относится к HotSpot и будет разобран отдельно. Сначала полезно понять, какие данные нужны для работы, а потом обсуждать, где конкретная JVM их хранит.

3. Где находятся объект и ссылка на него?

Массив — объект с ячейками данных. Переменная first может хранить ссылку на этот массив: значение, через которое Java находит объект. Копирование ссылки похоже на выдачу второго адреса одного склада: склад от этого не удваивается. Две переменные способны указывать на один и тот же объект.

В учебном фрагменте создаём массив из двух чисел и сохраняем его ссылку ещё в одной переменной. Затем меняем первую ячейку через вторую переменную.

int[] first = {4, 8};
int[] second = first;
second[0] = 99;
System.out.println(first[0]); // 99

1. {4, 8} создаёт один массив. Переменная first позволяет к нему обратиться.
2. second = first копирует значение ссылки. Отдельный массив здесь не создаётся.
3. second[0] = 99 меняет ячейку с индексом 0, то есть первый элемент общего массива.
4. first[0] читает ту же ячейку. Поэтому выводится 99.

В логической модели память объектов и массивов относится к heap. Но фраза «ссылка всегда в стеке» слишком широка: ссылка может быть локальным значением, полем другого объекта или элементом массива. Оптимизатор также способен обойтись без отдельной физической ячейки для некоторых значений. Для объяснения кода важнее различать объект и пути обращения к нему, чем придумывать точные адреса.

4. Чем metaspace отличается от heap?

Для каждого заказа приложение создаёт объект с номером и суммой. Отдельно JVM должна знать, что такое класс заказа: какие у него поля, методы и правила выполнения. В HotSpot данные об устройстве загруженных классов, метаданные, хранятся в metaspace. Эта область использует память процесса за пределами обычного Java heap, называемую здесь native memory.

Объект Class, который доступен Java-коду и представляет класс, сам остаётся Java-объектом. Поэтому нельзя складывать всё, что связано со словом «класс», в metaspace. Также память процесса нужна для стеков потоков, машинного кода JIT, прямых буферов обмена данными и внутренних структур JVM.

-Xmx задаёт максимальный размер Java heap, а не всей памяти приложения. Если создаётся всё больше классов либо сохраняются ненужные загрузчики классов, может закончиться metaspace. Увеличение -Xmx не уберёт эти связи и не увеличит автоматически нужную область. В диагностике важно понять, какая именно память растёт.

5. Escape analysis всегда переносит локальные объекты на стек?

Предположим, метод создаёт объект с двумя координатами только ради их суммы. Никто больше объект не получает. Оптимизатор может заметить, что отдельная упаковка этих двух чисел не нужна: достаточно самих значений. Исследование того, куда доступен объект за пределами метода или потока, называется escape analysis, анализом выхода.

В HotSpot одна из возможных оптимизаций — scalar replacement, замена работы с объектом отдельными значениями его полей. Выделение памяти под самостоятельный объект может исчезнуть. Это не обещание перенести тот же объект из heap в стек. При подходящих условиях могут устраняться и ненужные блокировки.

Сам факт, что переменная локальная, ничего не гарантирует: метод мог передать ссылку дальше. Результат зависит от путей выполнения, вызываемых методов, решения JIT и версии JVM. Поэтому ни слово new не доказывает фактическую стоимость выделения, ни краткость метода не доказывает отсутствие затрат. Скорость и объём выделений проверяют измерением.

Достижимость, утечки и ресурсы

6. Как GC понимает, что объект больше не нужен? Мешают ли циклы?

GC, garbage collector, — сборщик мусора: механизм автоматического освобождения памяти объектов. Он не понимает, завершён ли заказ с точки зрения бизнеса. Он проверяет достижимость: можно ли дойти до объекта по цепочке сохраняемых ссылок из начальных точек, которые JVM должна учитывать.

Такие начальные точки называют GC roots. С ними связывают, например, нужные ссылки в данных работающих потоков, доступных классах и взаимодействии с native-кодом; точное устройство зависит от реализации. Представьте схему: работающий код → список заказов → конкретный заказ. Пока путь сохраняется, объект доступен. Такую схему объектов и связей называют графом.

Два объекта могут ссылаться друг на друга, но если из начальных точек к ним нет пути, сам этот круг их не удерживает. Трассирующие сборщики ищут пути, а не просто считают все ссылки. Обратная ситуация важнее: заказ уже бесполезен для приложения, но остаётся в общем списке. GC видит путь к нему и сохраняет объект. Пригодность для сборки также не задаёт точный момент освобождения.

7. Почему утечки памяти возможны при наличии GC?

Память может занимать объект, который программа больше не использует, но всё ещё хранит. Например, кэш — хранилище для повторного использования результатов — пополняется и никогда не удаляет старые отчёты. Другая причина: обработчик событий остался зарегистрированным после закрытия экрана. Для GC эти объекты всё ещё достижимы, хотя их полезная жизнь закончилась.

В учебном примере карта cache хранит массив по ключу "report". Локальную переменную затем обнуляют. Посмотрим, исчезнет ли от этого запись.

Map<String, byte[]> cache = new HashMap<>();
byte[] page = new byte[16];
cache.put("report", page);
page = null;
System.out.println(cache.containsKey("report")); // true
cache.remove("report");

1. new byte[16] создаёт массив из 16 байтов; page хранит ссылку на него.
2. put("report", page) сохраняет в карте ещё одну ссылку на тот же массив.
3. page = null убирает связь из переменной page, но не запись карты. Поэтому containsKey("report") выводит true.
4. remove("report") удаляет связь из карты. Если других удерживающих путей нет, массив может быть собран; точное время эта строка не назначает.

Похожая ошибка бывает с ThreadLocal, значением, привязанным к потоку: задача закончилась, а переиспользуемый рабочий поток хранит её данные дальше. Ищут, кто удерживает объект и когда обязан удалить связь. Увеличение памяти может отложить сбой, но не устранить накопление. При этом рост кэша сам по себе ещё не утечка: нужны ожидаемые предел и срок хранения.

8. Чем strong, soft, weak и phantom references отличаются на практике?

Обычная ссылка из переменной или поля — strong reference, сильная ссылка. Пока объект достижим по таким связям из начальных точек, он сохраняется. Специальные объекты-ссылки позволяют держать связь с другими условиями. Они нужны для отдельных способов хранения и уведомлений о сборке, а не для ручного назначения времени удаления.

SoftReference, мягкая ссылка, допускает освобождение объекта с учётом потребности в памяти. WeakReference, слабая ссылка, не удерживает объект, когда к нему уже нет более сильных путей достижимости. PhantomReference, фантомная ссылка, используется с очередью уведомлений: через её get() нельзя снова получить объект для работы.

Здесь нет обещания «мягкая живёт десять минут, слабая удаляется немедленно». У мягкого кэша непредсказуемы ёмкость и сроки хранения. Слабая ссылка не подходит, если данные обязательно должны остаться. У WeakHashMap слабые ключи тоже не помогут, если значение само сильно ссылается на ключ: появится удерживающий путь. Сначала определяют, сколько хранить данные и кто ими владеет, затем выбирают инструмент.

9. Почему GC не заменяет close() для файла или соединения?

Java-объект открытого файла и сам доступ к файлу со стороны операционной системы — разные вещи. Объект занимает память; открытый файл использует системный ресурс. Соединение с базой дополнительно может занимать одно из ограниченного числа доступных подключений. Эти ресурсы нужны другим операциям сразу после окончания текущей работы.

GC освобождает память по своим правилам и не обещает сделать это к нужному моменту. Поэтому срок освобождения внешнего ресурса задают явно через close(). Конструкция try-with-resources связывает закрытие с выходом из определённого блока. Сборка объекта когда-нибудь потом не заменяет это соглашение.

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

10. System.gc() и finalize() позволяют управлять моментом освобождения?

System.gc() — просьба к JVM приложить усилия к сборке. Это не команда «удали выбранный объект прямо сейчас». API не обещает освободить конкретный объём, обработать определённое число объектов или закончить к заданному моменту. Поэтому тест, требующий пустую слабую ссылку сразу после вызова, опирается на отсутствующую гарантию.

finalize() — старый механизм, при котором JVM могла вызвать специальный метод объекта в ходе финализации. Он тоже не обеспечивает своевременного освобождения; начиная с JDK 18 финализация помечена на удаление. Для нового кода нужен явный срок жизни ресурса, а не надежда на этот метод.

Полезно разделять три события: объект стал доступен для сборки; его память стала доступна новым объектам; часть памяти процесса возвращена операционной системе. Они не обязаны совпадать по времени. Поэтому график памяти процесса после завершения запроса не обязан сразу снижаться, даже если в программе нет утечки.

Сборка мусора и производительность

11. Зачем сборщики используют поколения?

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

Это не обязательно одна неизменная физическая карта памяти. Области Eden, Survivor и Old встречаются в описаниях конкретных сборщиков, но их нельзя объявлять обязательным устройством любой JVM. Точные фазы, пороги перемещения и даже используемая поколенческая модель зависят от сборщика и версии.

Сложность появляется и на границе: старый объект может хранить ссылку на молодой. Чтобы проверить молодых, не теряя такие связи, сборщик должен учитывать обращения между областями. Перемещение живых объектов и учёт этих ссылок тоже стоят ресурсов. На собеседовании достаточно сначала объяснить, зачем используют возраст, а точные пороги обсуждать для указанной конфигурации.

12. Concurrent GC означает отсутствие остановок приложения?

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

Некоторые этапы требуют остановить его потоки. Такой промежуток называют stop-the-world pause, паузой приложения. Кроме того, даже фоновая работа сборщика использует процессор и память. Поэтому нужно смотреть не только максимальную паузу, но и их частоту, затраты на сборку и количество полезной работы за единицу времени — пропускную способность.

Задержка отдельного запроса — другое измерение. Он может ждать базу, занятый замок или свободное процессорное время. Даже короткие паузы GC не доказывают быстрый ответ каждого запроса. Сначала устанавливают, где именно теряется время, затем выбирают настройку.

13. Как выбрать сборщик и можно ли просто увеличить Xmx?

У разных приложений разные задачи: одному важен быстрый ответ на каждый запрос, другому — обработка большого пакета данных за ночь. Выбор сборщика начинается с этих требований, версии JDK, доступной памяти и объёма данных, которые действительно должны жить. Универсального названия «лучший GC» без условий нет.

Для сравнения записывают исходные показатели: как распределено время ответа, сколько занят процессор, как быстро создаются новые объекты, как часто и надолго идут сборки. Затем проверяют изменение на похожей нагрузке, меняя немного параметров за раз. Иначе трудно понять, что дало эффект.

Увеличенный heap иногда позволяет собирать реже, но требует больше памяти и меняет затраты некоторых фаз. Он не удаляет бесполезно удерживаемые объекты. Если среда ограничивает память всего процесса, большой -Xmx может не оставить места остальным областям. Флаги сборщика также зависят от версии: рабочую настройку нельзя переносить вслепую.

Загрузка и инициализация классов

14. Loading, linking и initialization — один этап?

Условно сначала нужно найти описание класса, затем подготовить его к использованию, потом выполнить начальную настройку. Loading, загрузка, находит class-файл или другое бинарное представление и создаёт представление класса в JVM. Linking, связывание, включает проверку допустимости, подготовку статических данных и разрешение ссылок на другие классы, поля и методы.

Разрешение ссылки означает, например, переход от имени вызываемого метода в class-файле к конкретному методу. Часть этой работы может быть отложена. Initialization, инициализация, выполняет предусмотренные присваивания статическим полям и статические блоки. Подготовить поле и исполнить написанный программистом инициализатор — разные шаги.

Одно упоминание имени класса в тексте не означает запуска его static-блока. Важны действия: создание экземпляра, вызов соответствующего статического метода, чтение неконстантного статического поля и другие предусмотренные случаи. Если инициализация сломалась, класс в том же загрузчике не получает обычную новую попытку при каждом обращении: ошибка меняет его состояние.

15. Чтение static final поля всегда запускает инициализацию?

Ключевое слово static связывает поле с классом, а final запрещает повторное присваивание. Но не каждое такое поле — константа времени компиляции. Для этого нужен примитивный тип либо String и константное выражение, например число 3. Значение такой константы может быть встроено в использующий код, без запуска инициализации объявившего класса.

В учебном Settings поле LIMIT — константа, а attempts получает значение вызовом mark(). Метод печатает init, чтобы сделать момент настройки заметным. Предполагаем, что до показанного фрагмента класс ещё не инициализирован.

class Settings {
    static final int LIMIT = 3;
    static int attempts = mark();
    static int mark() {
        System.out.println("init");
        return 7;
    }
}
// В другом классе, в методе main:
System.out.println(Settings.LIMIT);
System.out.println(Settings.attempts);

1. Первый println использует константу LIMIT. Печатается 3, инициализация Settings из-за этого не запускается.
2. Для чтения обычного статического поля attempts требуется инициализация класса.
3. Она вызывает mark(): появляется строка init, а возвращённое число 7 записывается в поле.
4. Чтение attempts теперь даёт 7, его печатает второй println. Порядок вывода: 3, init, 7.

static final Integer или значение, полученное вызовом метода, не является такой константой. Есть и практическое следствие встраивания: старый скомпилированный клиент может продолжать использовать прежнее значение публичной константы, пока его не перекомпилируют. final не означает автоматическое обновление уже собранного кода.

16. Могут ли два класса с одинаковым именем быть разными типами?

Класс в работающей JVM определяется не только именем вроде example.Report. Важно, какой загрузчик классов определил его. Если два независимых загрузчика каждый определили класс с этим именем, получатся разные типы, даже если тексты имён совпадают.

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

Часто загрузчик сначала просит родительский загрузчик найти общий класс: это называют делегированием. Если оба используют уже определённый родителем тип, описанного разделения не будет. Но не всякая система обязана всегда применять один порядок parent-first. При конфликте проверяют не только пакет и имя, но также загрузчик и источник класса.

Ошибки памяти и диагностика

17. Чем StackOverflowError отличается от OutOfMemoryError?

Вспомним кадры вызовов. Если метод вызывает сам себя без подходящего завершения, новые кадры добавляются, а старые не убираются. Когда глубина превышает доступный предел стека, возникает StackOverflowError. Рекурсия — частый учебный пример, хотя слишком глубокая цепочка возможна и с разными методами.

OutOfMemoryError означает невозможность удовлетворить запрос памяти. Это может быть heap, metaspace, прямые буферы или ресурсы для новых платформенных потоков. Одно название ошибки ещё не отвечает, что именно закончилось; важны полный текст и обстоятельства.

Увеличение стека допускает более глубокие вызовы, но увеличивает потребность в памяти при множестве потоков. Увеличение heap не лечит любую другую область. Перехват Error также не доказывает, что операцию можно безопасно повторить: часть работы могла уже выполниться, а ресурс по-прежнему недоступен. Сначала ищут причину, затем выбирают исправление.

18. Что выбрать: thread dump, heap dump, histogram или JFR?

Инструмент выбирают по вопросу. Если программа ждёт, нужен thread dump: снимок потоков, их состояний, вызовов и блокировок. Если растёт число живых объектов, heap dump сохраняет объекты и связи для поиска удержания. Histogram, гистограмма объектов, показывает количество и суммарный размер по классам, но не полный путь, который сохраняет конкретный объект.

JFR, Java Flight Recorder, записывает события во времени: можно сопоставить выделение памяти, сборки и ожидания. Снимок отвечает «что было в этот момент», запись помогает понять «что происходило перед задержкой». Конкретные события и затраты зависят от настроек.

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

jcmd <pid> help
jcmd <pid> GC.heap_info
jcmd <pid> Thread.print
jcmd <pid> help GC.heap_dump

1. help показывает, какие команды поддерживает выбранная JVM.
2. GC.heap_info запрашивает сводку о heap; она помогает начать проверку памяти.
3. Thread.print запрашивает сведения о потоках для разбора ожиданий и вызовов.
4. help GC.heap_dump показывает параметры создания дампа. Эта строка ещё не создаёт файл дампа.

Дамп heap и гистограмма могут заметно повлиять на работу; дамп требует места и содержит реальные данные объектов. Место сохранения и подходящий момент выбирают заранее. Native Memory Tracking в HotSpot учитывает определённые категории памяти JVM, но обычно требует включения при запуске и не является полным учётом произвольной памяти стороннего native-кода.

19. Почему один замер nanoTime не доказывает, что код быстрее?

Первый вызов метода может включать загрузку класса и начальную компиляцию. После многих вызовов JIT получит больше сведений и выберет другие оптимизации. Если результат вычисления нигде не нужен, часть работы может вообще исчезнуть из машинного кода. Поэтому одно маленькое число времени ещё не доказывает быстроту выбранного решения.

System.nanoTime() измеряет прошедшее время, но не устраняет эти эффекты, сборки мусора и фоновые процессы. Для небольших сравнений используют продуманную методику, например JMH — набор средств для Java-микробенчмарков. Прогрев, отдельные запуски и использование результата помогают избежать типичных ошибок; сам инструмент не делает любой эксперимент правильным.

Наконец, быстрый фрагмент не равен быстрому приложению: настоящая нагрузка может упираться в сеть или базу. Сравнивают сопоставимые условия и несколько наблюдений, а не выдают время одного учебного запуска за свойство любой JVM, коллекции или сборщика.

Что объяснить своими словами перед интервью

Нарисуйте один массив и две стрелки к нему. Уберите одну стрелку и объясните, почему массив ещё доступен через вторую. Затем добавьте кэш и покажите, какая запись сохранит данные после окончания запроса. В примере с классом Settings отдельно проследите каждый шаг до появления init.

Для задачи о сбое сначала назовите симптом и нужное наблюдение. При росте всей памяти и стабильном heap проверьте другие области. При медленном ответе установите, связано ли ожидание со сборкой, замком или внешней системой. Такой ответ показывает понимание работы программы и помогает выбрать следующий шаг без универсального рецепта «увеличить память».