Кэш использует SoftReference, но после обычной сборки мусора часть записей исчезает при свободном heap. Какую гарантию на время жизни таких ссылок даёт JVM?
SoftReference не гарантирует сохранность объекта до исчерпания heap. JVM может очистить мягкую ссылку во время сборки мусора, если считает это целесообразным, поэтому такой кэш допускает потерю записей в любой момент.
Мягкие ссылки появились как механизм для кэшей, содержимое которых желательно сохранять, пока у JVM достаточно памяти. Они должны были дать сборщику мусора возможность освободить кэш автоматически, вместо немедленного падения приложения из-за нехватки памяти.
Это компромисс между обычной ссылкой, которая удерживает объект безусловно, и слабой ссылкой, которая не препятствует сборке объекта при отсутствии сильных ссылок.
Разработчик может ошибочно считать, что SoftReference означает: «объект будет жить до почти полного заполнения heap». На практике очистка может произойти раньше, а точный момент и объём очистки зависят от реализации JVM, сборщика мусора и текущего давления на память.
Если приложение воспринимает кэш как хранилище обязательных данных, очистка ссылок приведёт к промахам, повторным вычислениям, дополнительным обращениям к базе или резкому росту задержек. При этом исчезновение записи не является признаком утечки или ошибки сборщика мусора.
Объект, на который указывают только мягкие ссылки, считается мягко достижимым. Во время обработки ссылок сборщик может очистить такую ссылку, после чего объект становится недостижимым и может быть освобождён. Если мягкая ссылка была очищена, вызов get() вернёт null.
Важно различать гарантию достижимости и политику очистки. JVM обязана корректно обрабатывать семантику ссылки, но не обязана сохранять объект до конкретного уровня заполнения heap или до возникновения OutOfMemoryError.
На практике реализация может учитывать возраст мягкой ссылки, объём доступной памяти и особенности конкретного сборщика. Эти эвристики не следует использовать как переносимый контракт приложения: поведение между версиями JVM и конфигурациями может отличаться.
Для кэша обычно безопаснее использовать обычные ссылки с явной политикой размера и вытеснения, например по LRU или LFU. Такой подход требует настройки и управления памятью, зато делает поведение предсказуемым. SoftReference допустима только для необязательных данных, повторное получение которых недорого и не создаёт опасной нагрузки.
Если нужно узнать момент очистки ссылки, её можно зарегистрировать в ReferenceQueue, но очередь сообщает уже о факте обработки ссылки, а не предоставляет гарантию, когда это произойдёт. Она также не превращает мягкий кэш в надёжное хранилище.
Сервис кэшировал результаты разбора схем через SoftReference. При штатной нагрузке часть ссылок периодически очищалась, из-за чего возрастало число повторных разборов и увеличивалась задержка запросов, хотя heap был заполнен лишь наполовину.
Рассматривались два варианта. Замена на обычные ссылки без ограничения размера устраняла промахи, но создавала риск неконтролируемого роста heap. Сохранение SoftReference не требовало лимита, однако не давало предсказуемой частоты промахов и ухудшало задержки в периоды активности GC.
Выбрали ограниченный кэш с явным размером и политикой вытеснения, а результат разбора сделали дешёвым для повторного создания. Это увеличило контроль над памятью и сделало задержки стабильнее; очистка кэша стала управляемым событием, а не побочным эффектом политики GC.
Да, семантически мягкая ссылка предназначена для объектов, которые JVM может сохранять дольше при наличии памяти, тогда как слабая ссылка обычно очищается при ближайшей обработке ссылок после исчезновения сильных ссылок. Но это не превращает SoftReference в гарантию длительного хранения: время жизни всё равно не определено контрактом приложения.
Не обязательно. Сборщик сначала очищает саму ссылку, если объект больше не имеет других сильных или подходящих достижимых ссылок. Затем объект может попасть в обычный цикл освобождения памяти текущего сборщика. Поэтому очистка ссылки и фактическое возвращение памяти — разные этапы.
Нет, такой гарантии нет. JVM может очистить мягкие ссылки, но приложение способно удерживать большой объём памяти обычными ссылками, нативными ресурсами, потоками или другими областями. Кроме того, даже после очистки мягких ссылок может не оказаться достаточно памяти для очередного выделения, поэтому проектировать защиту от OutOfMemoryError только на этом механизме нельзя.