Модель памяти JVM

Стек: свой у каждого потока и меньше, чем кажется

Бесконечная рекурсия свалилась на глубине 17533 вызовов. Добавил тому же методу пять аргументов - три long, double и ссылку - и та же рекурсия умерла на 5895. Поставил -Xss256k: 1782 и 980 соответственно.

Считаем вслух. По умолчанию поток на Linux x64 получает 1 МиБ стека (флаг ThreadStackSize=1024, в килобайтах). Миллион байт на 17533 фрейма - около 60 байт на пустой фрейм. Фрейм с пятью аргументами занял втрое больше, потому что аргументы и локальные переменные лежат прямо в нём. Поэтому «на какой глубине упадёт рекурсия» - вопрос без универсального ответа: считай размер фрейма, а не вызовы.

В стеке лежат фреймы вызовов, а в них локальные примитивы и ССЫЛКИ. Объект от new всегда уходит в кучу, на стеке остаётся ссылка. Кончился стек - StackOverflowError, причём с пустым message: тексту уже негде разворачиваться.

static int depth = 0;
static void rec() { depth++; rec(); }

// пустой фрейм:          глубина 17533, message = null
// фрейм с 5 аргументами: глубина 5895
// то же с -Xss256k:      1782 и 980

-Xss

размер стека потока, по умолчанию 1 МиБ

StackOverflowError

кончился стек потока, message пустой

Куча: почему new стоит дешевле, чем ты думаешь

Прогнал 20 миллионов аллокаций по 100 байт - 279 мс. Выключил флагом -XX:-UseTLAB, повторил - 1556 мс. Сборок мусора при этом было поровну: 387 и 385.

Замедление в 5,6 раза дала не уборка, а сама выдача памяти. С TLAB (thread-local allocation buffer) поток забирает себе кусок eden и раздаёт из него объекты сдвигом указателя, без всякой синхронизации - несколько машинных инструкций на аллокацию. Без TLAB каждый new лезет к общему указателю через атомарную операцию, и потоки дерутся за одну кэш-линию.

Куча поколенческая, из наблюдения «большинство объектов умирает молодыми». Новые рождаются в eden, пережившие сборку копируются в survivor, зрелые переезжают в old - это называется promotion. Механика тут важнее названий: молодая сборка копирует ВЫЖИВШИХ и объявляет остальное свободным, мёртвых она не трогает вообще.

TLAB

потоковый буфер аллокации: new без синхронизации

eden / survivor / old

зоны поколений: рождение, отсев, долгожители

Четыре разных OutOfMemoryError

Набивал -Xmx64m мегабайтными массивами: на 58-м прилетело OutOfMemoryError: Java heap space. Грузил классы при -XX:MaxMetaspaceSize=5m - получил OutOfMemoryError: Metaspace. А при -Xmx128m аллокация direct-буферов упала на Cannot reserve 1048576 bytes of direct buffer memory (allocated: 128983040, limit: 129761280).

Посмотри на числа в третьей ошибке: лимит direct-памяти вышел 129761280 байт, то есть ровно заданные 128 мегабайт. По умолчанию MaxDirectMemorySize равен максимуму кучи, и процесс имеет право занять примерно вдвое больше -Xmx - две половины считаются раздельно. Четвёртый сорт - «unable to create native thread»: упёрлись в лимит потоков операционной системы, а память тут ни при чём.

// Metaspace - память под метаданные классов, и живёт она в нативной памяти: так называют память, которую процесс берёт у операционной системы напрямую, минуя кучу, поэтому сборщик её не убирает и -Xmx её не ограничивает. С Java 8 она пришла на смену PermGen и по умолчанию идёт без потолка: MaxMetaspaceSize равен 18446744073709551615. Растёт с числом загруженных классов, поэтому горячий редеплой и генерация прокси раздувают её тихо.

Metaspace

нативная память под метаданные классов, по умолчанию без потолка

MaxDirectMemorySize

лимит direct-буферов, по умолчанию равен -Xmx

Контейнер: сколько JVM возьмёт без спроса

Запустил java в контейнере с лимитом 1600 МиБ и распечатал итоговые флаги: MaxHeapSize=419430400, InitialHeapSize=27262976. Это 400 МиБ и 26 МиБ.

Проверяем: 400 из 1600 - ровно четверть, и действительно MaxRAMPercentage по умолчанию 25.000000. Стартовая куча - 1.562500 процента лимита, одна шестьдесят четвёртая. Считает JVM от лимита контейнера, а не от памяти всего сервера: лимит записан в cgroups - это механизм ядра Linux, которым Docker ограничивает процессу память и процессор, и JVM умеет его читать. Поэтому в контейнере удобнее задавать -XX:MaxRAMPercentage: переедешь на под пожирнее, и куча вырастет сама.

Ловушка, на которой горят: поставить -Xmx равным лимиту контейнера. Мой замер по шагам - старт процесса 36 МиБ RSS, после ста direct-буферов 140 МиБ при занятой куче в 1 МиБ, плюс 300 потоков 168 МиБ. Вне -Xmx живут Metaspace, стеки потоков, direct-буферы, скомпилированный код и сам рантайм. Оставь им запас, иначе OOMKilled придёт при пустой куче.

MaxRAMPercentage

куча как процент от лимита контейнера, по умолчанию 25

RSS

resident set size, реально занятая процессом память

Как отвечать: «Чем стек отличается от кучи и что где хранится?»

Стек свой у каждого потока: фреймы вызовов, в них локальные примитивы и ссылки. По умолчанию это мегабайт, и глубина рекурсии зависит от размера фрейма - у меня пустая рекурсия дошла до 17533 вызовов, а с пятью аргументами только до 5895. Куча общая, в ней лежат все объекты от new, её убирает сборщик. Куча поколенческая: новые объекты рождаются в eden через TLAB, то есть сдвигом указателя без синхронизации - когда я выключил TLAB, те же аллокации замедлились в пять с половиной раз. Пережившие сборку едут в survivor, потом в old. Отдельно от кучи живут Metaspace под метаданные классов, стеки потоков и direct-буферы, и для контейнеров это ключевое: -Xmx ограничивает только кучу, а процесс занимает заметно больше. Отсюда и разные падения: StackOverflowError, OutOfMemoryError по куче, по Metaspace и по direct-буферам.

Почему это сильный ответ: разведены владение и содержимое, названа механика аллокации вместо общего «куча общая», и сделан выход на прод - почему потребление процесса не равно -Xmx.

На чём валят

• −«Маленькие объекты живут на стеке». На стеке лежат ссылки; аллокацию может убрать escape analysis, но это работа JIT (just-in-time, компиляция на лету), а не правило языка.
• −-Xmx равен лимиту контейнера. В моём замере куча занимала 1 МиБ при RSS 168 МиБ: Metaspace, стеки и direct-буферы не поместились - OOMKilled.
• −«OutOfMemoryError один». Их четыре сорта, и лечатся они по-разному: куча, Metaspace, direct-буферы, потоки ОС. Читай хвост сообщения.
• −Считать direct-буферы частью -Xmx. У них отдельный лимит, по умолчанию равный -Xmx, то есть суммарно вдвое больше.
• −Ловить OutOfMemoryError и продолжать работу. Свободной памяти по-прежнему нет, а часть структур уже недостроена; правильный ход - падать и рестартовать.