Сборка мусора

Большинство объектов умирает молодыми — слабая поколенческая гипотеза. Young gen (eden и два survivor-пространства) очищается частыми дешёвыми minor GC, копирующими немногих выживших; они продвигаются в old gen, собираемый редко, но дорого.

Сборка мусора — это автоматическое освобождение JVM объектов в heap, до которых больше нет ни одной живой ссылки. Она избавляет разработчика от ручного управления памятью — нет free или delete, — что предотвращает большинство утечек и висячих указателей. Цена в том, что время сборки недетерминировано: нельзя предсказать, когда именно объект будет освобождён.

Статическая final карта — это GC root, держащий сильную ссылку на каждый разобранный Session, поэтому ни одна запись не становится недостижимой и сборщик не может её освободить: это утечка по достижимости, а не сбой GC. Лечится ограничением кэша — LRU через LinkedHashMap.removeEldestEntry или WeakHashMap, чьи записи очищаются, как только не остаётся сильных ссылок на ключ.

Сильная ссылка — по умолчанию — держит объект достижимым и не даёт его собрать. SoftReference очищается только под нехваткой памяти, поэтому подходит для чувствительных к памяти кэшей. WeakReference очищается на ближайшей сборке, как только не осталось ни одной сильной ссылки, — так работают ключи WeakHashMap. PhantomReference нельзя разыменовать (get() всегда возвращает null); она лишь ставится в ReferenceQueue после сборки — безопасный хук очистки вместо finalize().

Нет — System.gc() лишь подсказка. JVM вправе её проигнорировать, а -XX:+DisableExplicitGC делает вызов no-op. Вызов в прикладном коде обычно запускает дорогой full GC и бьёт по throughput; это не способ освободить память или устранить утечку.

Занятость old gen O держится выше 97% и не падает после full GC, а FGC и FGCT растут круто — это идущие подряд полные сборки, которые почти ничего не освобождают. Признак удерживаемого живого набора (утечки), а не малого young gen. Подтверждают heap dump (jmap -dump), разобранный в Eclipse MAT или VisualVM, — его dominator tree называет удерживающий GC root, — плюс -Xlog:gc* или JFR для истории пауз.

Serial использует один поток, годится для малых куч. Parallel использует много потоков, максимизируя пропускную способность. CMS был конкурентным, но теперь удалён. G1 (garbage-first) — сборщик по умолчанию: порегионный, балансирует пропускную способность и предсказуемые паузы. ZGC и Shenandoah дают очень низкие паузы, не зависящие от размера кучи. Ключевой компромисс — пропускная способность против времени паузы.

ZGC выполняет маркировку, перемещение объектов и переадресацию ссылок конкурентно с работающим приложением. Цветные указатели хранят состояние GC в незанятых битах адреса, а load barrier на каждом чтении ссылки лениво переадресует устаревший указатель. Stop-the-world остаются лишь короткие сканы корней, поэтому пауза зависит от размера корневого набора, а не от размера кучи.

G1 Humongous Allocation помечает объекты крупнее половины региона: они выделяются сразу в old gen и собираются плохо. Они фрагментируют кучу, пока эвакуации не остаётся ни одного свободного региона (To-space exhausted), и G1 откатывается к полной stop-the-world компактизации — отсюда многосекундные паузы. Целевое время паузы не переживает откат к full GC. Правьте саму аллокацию, увеличьте -XX:G1HeapRegionSize и снизьте InitiatingHeapOccupancyPercent, чтобы конкурентный цикл стартовал раньше.

Гистограмма показывает, что AuditEntry — и удерживаемые им byte[]/String — растут без ограничений синхронно с числом запросов, удерживаемые через HashMap$Node. Бин аудита копит по записи на запрос и ничего не вытесняет. Singleton-бин Spring живёт столько же, сколько контекст приложения, поэтому всё, что он накопил, остаётся достижимым, и GC правомерно это не освобождает. Подтвердите путь удержания по dominator tree в heap dump и ограничьте буфер размером или политикой вытеснения.