При профилировании видно, что многопоточное приложение создаёт объекты без заметной конкуренции за heap. Как JVM обычно достигает этого?
Обычно JVM выдаёт каждому Java-потоку собственный TLAB — небольшой участок Eden в куче. Поток выделяет объекты внутри него локальным перемещением указателя, поэтому для большинства мелких аллокаций не требуется общая блокировка или атомарная операция.
Когда TLAB заканчивается, поток запрашивает новый участок у JVM. Крупные объекты или ситуации, в которых объект не помещается в TLAB, выделяются отдельным путём.
Наивное выделение каждого объекта из общего свободного пространства требует синхронизации между потоками. При интенсивном создании короткоживущих объектов такая синхронизация сама становится узким местом.
TLAB появился как оптимизация распределения памяти: общая синхронизация выполняется редко, при получении нового буфера, а не на каждой аллокации. Это особенно эффективно для типичной модели Java, где большинство объектов живёт недолго и создаётся в молодом поколении.
Если все потоки будут обращаться к одному общему указателю свободной памяти, каждое создание объекта может потребовать атомарной операции или другой координации. При высокой нагрузке это увеличит задержки и снизит масштабируемость приложения.
Однако TLAB не устраняет стоимость выделения памяти полностью. Слишком маленькие буферы вызывают частые запросы новых TLAB, слишком большие могут оставлять неиспользованное пространство при завершении работы потока или сборке мусора.
При создании потока JVM резервирует ему TLAB в области, предназначенной для молодых объектов, обычно в Eden. Внутри TLAB находятся границы текущего свободного пространства и адрес следующей аллокации.
Для небольшого объекта JVM проверяет, что в TLAB достаточно места, записывает объект по адресу свободного указателя и сдвигает этот указатель на размер объекта. Такой путь обычно очень короткий и не требует обращения к общей структуре распределения памяти.
Когда места не хватает, JVM завершает использование текущего TLAB и получает новый. Получение нового буфера требует координации с другими потоками, но происходит значительно реже, чем создание объектов.
Объект, который слишком велик для TLAB, может быть выделен вне TLAB. Точный путь зависит от сборщика мусора, размера объекта и текущего состояния памяти; для некоторых сборщиков крупные объекты имеют особые правила размещения.
TLAB не означает, что объект принадлежит потоку на протяжении всей жизни. После создания объект доступен другим потокам через обычные ссылки и затем обрабатывается сборщиком мусора независимо от того, какой поток его выделил.
На поведение также влияют escape analysis и скаляризация: JIT может доказать, что некоторые объекты не покидают метод, и устранить их фактическое размещение в куче. Поэтому число логических созданий объектов в коде не всегда совпадает с числом heap-аллокаций.
Размер TLAB подбирается JVM адаптивно и зависит от темпа аллокаций, числа потоков и параметров среды. Увеличение TLAB может снизить частоту обращений за новым буфером, но повысить внутренние потери памяти и объём пространства, который потенциально придётся учитывать при сборке мусора.
Сервис обрабатывает запросы в большом пуле потоков и создаёт множество временных объектов. Профилирование показывает высокую скорость аллокаций, но CPU не тратится заметно на блокировки при выделении памяти; при этом после увеличения числа потоков вырос объём неиспользуемого пространства в Eden.
Рассматривались два варианта. Увеличение TLAB могло уменьшить частоту его пополнения, но увеличивало потенциальные потери памяти и не решало проблему избыточного числа потоков. Уменьшение TLAB сокращало такие потери, но повышало частоту медленного пути получения нового буфера.
Выбранным решением стало не механическое изменение размера TLAB, а уменьшение избыточной конкуренции за CPU и настройка размера пула потоков по измерениям. Дополнительно проверили профили аллокаций и влияние escape analysis. Это сохранило быстрый локальный путь выделения и уменьшило суммарные потери памяти без ухудшения задержек.
Нет. TLAB оптимизирует только путь выделения памяти. Объекты по-прежнему попадают в область, управляемую выбранным сборщиком, могут переживать молодые сборки и продвигаться дальше, если остаются достижимыми.
Следовательно, высокий темп аллокаций может оставаться причиной частых сборок мусора даже при отсутствии конкуренции за выделение. TLAB снижает стоимость создания объектов, но не количество объектов и не объём памяти, который они занимают.
Большой TLAB уменьшает число операций получения новых буферов, но может привести к большему объёму неиспользованного пространства. При большом количестве потоков суммарный резерв таких буферов становится заметным.
Кроме того, размер TLAB не исправляет проблемы, вызванные долгоживущими объектами, чрезмерным числом потоков или неэффективной структурой данных. Решение нужно принимать по профилю аллокаций, паузам GC и фактической загрузке памяти, а не по одному показателю.
Профилирование аллокаций обычно фиксирует факт и объём выделения за некоторый период, а heap dump показывает состояние достижимых объектов в конкретный момент. Короткоживущий объект может быть создан, использован и собран до снятия дампа.
Кроме того, часть объектов может быть устранена JIT-компилятором благодаря escape analysis, а данные профилировщика могут включать статистику, собранную с выборкой. Поэтому heap dump, статистика TLAB и allocation profiling отвечают на разные вопросы и не обязаны совпадать по числам.