Краткий ответ

JIT-компилятор может применить анализ escape-анализа и скалярную замену: вместо создания объекта в куче он раскладывает его поля на отдельные локальные значения. В этом случае аллокация и последующая работа GC могут исчезнуть, но это оптимизация, а не гарантированное свойство Java-программы.

Исторический контекст

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

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

Постановка проблемы

Если временный объект действительно создаётся в куче, JVM должна выделить для него память, инициализировать поля, а позднее обработать его при сборке мусора. В горячем коде большое число таких объектов может увеличить частоту сборок, задержки и потребление памяти.

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

Подробное решение

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

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

static int distanceSquared(int x, int y) {
    Point p = new Point(x, y);
    return p.x * p.x + p.y * p.y;
}

static final class Point {
    final int x, y;
    Point(int x, int y) { this.x = x; this.y = y; }
}

В этом примере JIT может устранить аллокацию Point, если метод стал горячим и анализ доказал отсутствие утечки ссылки. Это не гарантируется: решение зависит от конкретной JVM, версии, профиля исполнения, доступности оптимизации и последующей деоптимизации.

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

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

Диагностика требует осторожности: профилировщик или heap dump может не показывать оптимизированный объект, потому что в момент съёмки его физически не существовало. Кроме того, отключение оптимизаций, изменение уровня прогрева или добавление диагностического кода способны изменить сам профиль исполнения.

Ситуация из практики

В сервисе после оптимизации метода снизилось число аллокаций, хотя исходный код продолжал создавать временные объекты-значения. Рассматривались три варианта: вручную переписать код на примитивы, оставить код как есть или подтвердить оптимизацию профилированием.

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

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

Что кандидаты часто упускают

Всегда ли устранение аллокации означает размещение объекта в стеке?

Нет. Это распространённое упрощение. При скалярной замене объект может вообще не иметь единого физического представления: его поля существуют как отдельные значения в регистрах или слотах. Размещение в стеке — лишь один из возможных вариантов, а не обязательный результат escape-анализа.

Может ли объект сначала не создаваться, а затем появиться во время выполнения?

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

Почему добавление логирования иногда меняет показатели GC и производительности?

Логирование может передать объект или его ссылку в отдельный вызов, сохранить её, вызвать отражение либо сделать поведение недостаточно прозрачным для JIT. Тогда доказательство отсутствия escape становится невозможным, и объект начинает реально создаваться в куче.

Кроме того, само логирование меняет прогрев, частоту вызовов и форму оптимизированного кода. Поэтому диагностический код способен не только измерять проблему, но и влиять на неё; результаты следует проверять на сопоставимой нагрузке и с учётом прогрева JVM.