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

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

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

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

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

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

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

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

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

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

Ключ WeakHashMap оборачивается в объект, использующий слабую ссылку. Сборщик мусора учитывает слабые ссылки: если объект доступен только через них, он может быть признан недостижимым и освобождён.

После обнаружения такого ключа сборщик помещает связанную ссылку в специальную очередь. При последующих операциях WeakHashMap очищает очередь и удаляет соответствующие записи. Поэтому удаление может фактически проявиться не строго в момент сборки мусора, а при следующем обращении к карте.

Ключевой риск — значение карты хранится обычной сильной ссылкой. Если значение прямо или косвенно ссылается на свой ключ, возникает путь сильной достижимости от карты к ключу через значение, и ожидаемое автоматическое удаление может не произойти.

Слабые ключи не означают слабую потокобезопасность: WeakHashMap не предназначена для конкурентного доступа без внешней синхронизации. Кроме того, её размер и содержимое могут измениться из-за сборки мусора, даже если прикладной поток не вызывал методы удаления.

import java.util.Map;
import java.util.WeakHashMap;

public class Example {
    public static void main(String[] args) {
        Map<Object, String> cache = new WeakHashMap<>();
        Object key = new Object();
        cache.put(key, "метаданные");
        key = null;
        // Запись может исчезнуть после сборки мусора.
        // Момент удаления не гарантирован.
    }
}

Преимущество подхода — автоматическое освобождение записей без явного удаления ключей. Компромисс — недетерминированное содержимое карты и невозможность использовать её для данных, которые должны сохраняться независимо от жизненного цикла ключа.

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

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

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

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

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

Удаляет ли WeakHashMap запись немедленно после того, как ключ стал недостижимым?

Нет. Сборщик мусора сам выбирает момент обработки слабых ссылок, а карта обычно очищает обнаруженные ссылки во время последующих операций. Поэтому проверка размера или наличие записи не даёт детерминированного результата относительно момента сборки мусора.

Может ли значение WeakHashMap помешать сборке ключа?

Да. Значение хранится сильной ссылкой. Если значение содержит ссылку на свой ключ, получается цепочка карта → запись → значение → ключ, и ключ остаётся сильно достижимым. Для таких случаев нужно не допускать обратной ссылки либо выбирать другую модель хранения.

Можно ли использовать WeakHashMap для реализации надёжного кэша с гарантированным временем хранения?

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