⚙️application / jvm

Утечка памяти JVM под нагрузкой

senior⏱ 35 min🏢 SaaS analytics platform (500k daily active users)
JVMHeap DumpJavaGCMemory LeakSpring Boot

Стек технологий

  • Java 17
  • Spring Boot 3.1
  • JVM 17 (G1GC)
  • Micrometer
  • Grafana
🚨

Сценарий инцидента

Ваш Analytics API без проблем обрабатывает 200 RPS в staging.
После деплоя в production (пик 600 RPS) сервис начинает выбрасывать OutOfMemoryError примерно через 45 минут нагрузки.
Размер хипа — 8 ГБ. Доступны GC-логи. Дамп кучи был снят незадолго до OOM.
У вас 30 минут до следующего окна деплоя. Найдите утечку.

🔍 Артефакты расследования

Раскрывай артефакты один за другим. Каждая улика приближает тебя к корневой причине.

📊
Улика #1 · graph
Использование хипа JVM за 45 минут
💡 Сравните поведение Eden/Survivor и Old Gen — одна область восстанавливается после GC, другая — нет
📋
Улика #2 · log
Анализ GC-логов (G1GC)
💡 Сосредоточьтесь на событиях Full GC — сколько памяти освобождается каждый раз?
🔍
Улика #3 · query
Анализ дампа кучи (гистограмма jmap)
💡 Какой класс имеет подозрительно большое число экземпляров? Кто является его владельцем?
⚙️
Улика #4 · config
Реализация SessionCache
💡 Чего не хватает в этой реализации кэша для предотвращения роста памяти?