Разберём, что такое heap, почему он кончается и как это исправить. Это полезно для разработчиков, кто работает с большими данными или многопоточными приложениями. Вы узнаете, как мониторить память, настраивать параметры и анализировать дампы.

Что такое Java Heap Space и как он работает

Java Heap Space, или просто heap, — это область памяти в JVM, предназначенная для хранения объектов, созданных с помощью оператора new. В отличие от stack, где живут локальные переменные методов, heap предназначен для долгоживущих данных: строк, массивов, коллекций и экземпляров классов. JVM автоматически управляет этой памятью через сборщик мусора (GC), который освобождает место от неиспользуемых объектов.

Представьте приложение, которое загружает большой файл в память: все данные окажутся именно в heap. Если объектов слишком много или они не очищаются timely, heap переполняется. Это приводит к java.lang.OutOfMemoryError: Java heap space — классической ошибке, которая стопорит весь процесс. Heap делится на поколения: Young (для новых объектов), Old (для выживших после GC) и иногда Metaspace (для метаданных классов). Каждый поток имеет свой stack, но heap общий для всех.

Вот основные характеристики heap:

• Размер настраивается флагами JVM: -Xms (начальный), -Xmx (максимальный).
• GC работает здесь циклично: minor GC чистит Young, major — Old.
• Мониторинг через инструменты вроде VisualVM или JConsole показывает occupancy в реальном времени.

Причины ошибки OutOfMemoryError: Java heap space

Ошибка OutOfMemoryError: Java heap space возникает, когда JVM не может выделить память для нового объекта под heap. Чаще всего это из-за недостаточного лимита -Xmx или утечек памяти, когда объекты остаются доступными по ссылкам и не собираются GC. Например, в веб-приложении на Spring Boot коллекция сессий растёт бесконтрольно — heap кончается за минуты.

Другие причины: чрезмерное создание временных объектов в циклах, загрузка огромных датасетов без пагинации или неправильная сериализация. В многопоточных приложениях каждый поток может генерировать объекты, нагружая общий heap. Не забывайте про non-heap память (Metaspace, Direct ByteBuffers), которая тоже может влиять косвенно. По умолчанию heap берёт 1/4 от доступной RAM, но на серверах с 8 ГБ это всего ~2 ГБ — мало для серьёзных задач.

Типичные сценарии переполнения:

• Утечки памяти: Статические коллекции, держащие ссылки на ненужные объекты.
• Пики нагрузки: Batch-обработка миллионов записей без батчинга.
• Неправильный GC: Длинные паузы из-за большого heap, когда GC не справляется.*
• Фатальные исключения: Рекурсия без лимита, заполняющая heap стеками вызовов.

Как настроить и оптимизировать Java Heap Space

Настройка heap начинается с флагов JVM при запуске: -Xms и -Xmx задают границы. Устанавливайте -Xms равным -Xmx, чтобы избежать resize heap во время работы — это экономит время и снижает фрагментацию. Для приложений с 16 ГБ RAM начните с -Xmx8g, но мониторьте: слишком большой heap удлиняет GC-паузы. Выбирайте GC под задачу: G1GC для больших heap (>4 ГБ), Parallel для throughput.

Проверьте текущий размер командой java -XX:+PrintFlagsFinal -version | grep HeapSize. На Linux с 8 ГБ RAM max heap ~2 ГБ по умолчанию — увеличьте явно. В Docker лимитируйте через --memory. Для тюнинга используйте инструменты: JVisualVM для live-графиков, jcmd <pid> GC.heap_dump для дампов. Анализируйте дампы в Eclipse MAT или YourKit, ищите dominators — объекты, занимающие больше всего места.

Практические шаги по настройке:

1. Запуск с параметрами: java -Xms2g -Xmx4g -XX:+UseG1GC -jar app.jar.
2. Мониторинг: jstat -gc <pid> 1s для статистики GC.
3. Heap dump на OOM: -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps/.

• Настройте GC логи: -Xlog:gc*:file=gc.log для анализа пауз.

Управление памятью вне heap и продвинутые техники

Помимо heap, JVM использует non-heap: Metaspace для классов, CodeCache для JIT-кода, Native для буферов. Они не видны в стандартном heap dump, но могут съедать RAM. Команда jcmd <pid> VM.native_memory покажет breakdown. Например, Off-heap память через ByteBuffer.allocateDirect() обходит GC, но требует ручного освобождения.

Для оптимизации: используйте пулы объектов (Apache Commons Pool), flyweight-паттерн для immutable данных, weak references для кэшей. В микросервисах лимитируйте heap на под 1-2 ГБ на контейнер. Тестируйте под нагрузкой с JMeter, измеряя heap usage. Профилируйте с JProfiler: ищите hot spots по аллокациям.

Ключевые техники:

• Пулы потоков: ExecutorService вместо new Thread().
• WeakHashMap: Автоочистка неиспользуемых ключей.
• Off-heap: Chronicle Map или MapDB для больших датасетов.*

Heap под контролем: ключевые метрики для слежения

Эффективное управление heap требует постоянного мониторинга. Следите за heap occupancy (процент заполнения), частотой GC и паузами. Если occupancy >80% chronically, увеличьте heap или оптимизируйте код. Инструменты вроде Prometheus + Grafana с Micrometer собирают метрики из JVM.

В долгосрочной перспективе думайте о смене GC (Shenandoah/ZGC для low-latency) или миграции на GraalVM с AOT. Это ускорит старт и снизит footprint. Остаётся место для глубокого разбора GC алгоритмов и кейсов из продакшена — тема для следующих статей.

Фокус на метриках поможет предсказывать OOM заранее. Собирайте heap dumps proactively и автоматизируйте алерты на 90% occupancy.