Краткий ответ

Слабая ссылка не удерживает объект от сборки мусора. Если на объект больше нет сильных или иных удерживающих ссылок, JVM может очистить слабую ссылку во время GC; после этого её get() вернёт null. Поэтому такой кэш допускает исчезновение записей и не гарантирует сохранность данных.

Исторический контекст

Обычная сильная ссылка удобна для управления временем жизни объектов, но плохо подходит для вспомогательных структур вроде кэшей, таблиц метаданных и ассоциативных структур, которые не должны сами препятствовать освобождению памяти.

Механизм ссылок из пакета java.lang.ref позволяет явно выразить более слабую зависимость между объектом и ссылкой. JVM получает возможность освобождать объект под давлением памяти, не считая наличие такой ссылки достаточной причиной для его сохранения.

Постановка проблемы

Предположим, приложение кэширует редко используемые объекты, например результаты разбора ресурсов или промежуточные представления данных. Если кэш хранит их сильными ссылками без ограничения размера, он может удерживать значительную часть heap и увеличить частоту или длительность сборок мусора.

Замена сильных ссылок на слабые решает проблему удержания памяти, но меняет семантику кэша: запись может исчезнуть между двумя обращениями без явного удаления. Это приводит к повторным вычислениям, промахам кэша и потенциально нестабильным задержкам.

Подробное решение

Объект считается доступным через слабую ссылку, когда до него нельзя добраться сильной или мягкой ссылкой, но путь через WeakReference ещё существует. Такой объект может быть выбран сборщиком мусора, а слабые ссылки на него очищаются.

После очистки WeakReference.get() возвращает null. Если ссылка зарегистрирована в ReferenceQueue, JVM может поместить её туда, чтобы приложение удалило соответствующую запись из собственной структуры кэша.

import java.lang.ref.WeakReference;

public class Demo {
    public static void main(String[] args) {
        Object value = new Object();
        WeakReference<Object> reference = new WeakReference<>(value);
        value = null;
        System.gc();
        System.out.println(reference.get()); // null или ещё доступный объект
    }
}

Вызов System.gc() является лишь запросом и не гарантирует немедленную сборку. Даже после него объект может временно оставаться доступным, поэтому результат примера недетерминирован.

Слабые ссылки подходят для необязательных данных, которые можно безопасно восстановить. Они не подходят для основного состояния приложения, результатов, которые должны сохраняться до явного истечения срока, или кэшей с жёсткими требованиями к hit rate.

Важно различать слабые ссылки и мягкие ссылки. Мягкие ссылки также не дают абсолютной гарантии сохранения объекта, но политика их очистки зависит от решения сборщика мусора; слабые ссылки предназначены для объектов, которые можно удалять сразу после исчезновения более сильных путей доступности.

Для предсказуемого кэша обычно лучше использовать сильные ссылки с ограничением размера, TTL или политикой вытеснения. Слабые ссылки уменьшают риск удержания памяти, но перекладывают на приложение последствия внезапных промахов и необходимость корректной очистки служебных записей.

Ситуация из практики

Сервис кэшировал разобранные шаблоны документов через слабые ссылки. После GC задержка обработки резко возрастала: шаблоны исчезали, и несколько запросов одновременно повторно выполняли дорогостоящий разбор.

Рассматривались три варианта. Сильный неограниченный кэш давал высокий hit rate, но мог исчерпать heap. Мягкие ссылки сохраняли данные дольше в благоприятных условиях, однако их поведение также зависело от GC и не давало строгих гарантий. Слабые ссылки минимизировали удержание памяти, но создавали непредсказуемые промахи.

Выбрали ограниченный сильный кэш с максимальным числом элементов и временем жизни записей. Для второстепенных, полностью восстанавливаемых данных оставили отдельный кэш на слабых ссылках с ReferenceQueue для удаления очищенных записей. Это обеспечило контролируемое потребление памяти и более стабильные задержки основного пути.

Что кандидаты часто упускают

Гарантирует ли слабая ссылка, что объект будет удалён на ближайшей сборке мусора?

Нет. Слабая ссылка только делает объект кандидатом на очистку, если отсутствуют более сильные пути доступности. Момент сборки зависит от конкретного сборщика, текущей нагрузки и других условий JVM; приложение не должно полагаться на точный момент очистки.

Почему одной слабой ссылки недостаточно для корректного кэша?

Потому что слабая ссылка не сообщает автоматически, какую запись в пользовательской структуре нужно удалить. После очистки значения объект-обёртка или запись в Map могут остаться, хотя get() уже возвращает null. ReferenceQueue позволяет обнаружить очищенные ссылки и удалить связанные записи, но соответствующую связь приложение должно организовать самостоятельно.

Чем опасна ошибка с WeakHashMap, когда значение косвенно ссылается на ключ?

WeakHashMap использует слабые ссылки на ключи, но значения хранятся сильными ссылками. Если значение прямо или через другой объект ссылается обратно на ключ, возникает сильный путь от самой map к ключу: map удерживает значение, а значение удерживает ключ. В результате ключ не становится недостижимым, и ожидаемого автоматического удаления записи не происходит.