Что проверяет вопрос «зачем в LinkedHashMap accessOrder»
По умолчанию LinkedHashMap хранит порядок вставки: сколько ни читай элементы, порядок в итераторе не меняется. Вопрос про accessOrder проверяет, знаете ли вы, что у класса есть второй режим.
С конструктором LinkedHashMap(capacity, loadFactor, true) порядок итерации становится порядком последнего доступа: и get(), и put() двигают элемент в конец списка. Именно на этом строят LRU-кэш без ручного связного списка.
Собеседующего интересует конкретика: removeEldestEntry() — protected-метод, который вызывается после каждого put(). Если вернуть true, самый старый или наименее недавно использованный элемент удаляется автоматически.
class LruCache extends LinkedHashMap {
private final int capacity;
LruCache(int capacity) { super(capacity, 0.75f, true); this.capacity = capacity; }
@Override protected boolean removeEldestEntry( Map.Entry eldest) { return size() > capacity; } }
Спросят следом: почему это не потокобезопасно и что будет при конкурентном get() на accessOrder=true карте. Ответ — связный список внутри мутируется при чтении, параллельный доступ без внешней синхронизации ломает саму структуру, не только данные.
Если видите вручную написанный LRU с HashMap и отдельным Deque — велика вероятность, что автор не знал про accessOrder.
Тренажёр: 600 вопросов, мок с таймером, план повторов
senior·base — что спрашивают на самом деле
В этом посте были ссылки, но мы их удалили по правилам Сетки
