Explain the contract of removeEldestEntry: when it's invoked, what 'eldest' means, and what returning true does.
answer
- Protected hook, override in a subclass
- Called after every insertion only
- eldest = head = oldest/LRU entry
- Return true → map removes it for you
- Don't mutate the map inside it
basics
~10 sremoveEldestEntry is a hook LinkedHashMap calls after each insertion, passing the oldest entry in its list. If your override returns true, LinkedHashMap removes that oldest entry; the default returns false, so nothing is auto-removed.
solid answer
~50 s`removeEldestEntry(Map.Entry<K,V> eldest)` is a protected hook LinkedHashMap invokes immediately after a new entry is added via put/putAll. The 'eldest' it passes is the head of its internal linked list — in insertion-order mode that's the first-inserted entry, in access-order mode the least-recently-used. The base class returns `false`, meaning the map never auto-evicts; you override it to return `true` when you want LinkedHashMap to remove that eldest entry for you. Crucially it's a *decision* method: you should not modify the map inside it (no manual remove) — just return the boolean and let the map do the removal. Because it fires per-insertion, at most one entry is evicted per put, so the map shrinks by at most one each time. The eldest entry is provided so you can inspect its key/value (e.g., to log eviction or veto removal of pinned entries), not so you can delete it yourself.
go deeper
Knows removeEldestEntry decides whether to drop the oldest entry and that returning true causes eviction.
States that it runs after insertions, that eldest is the head, and that you return a boolean rather than removing manually.
Explains the per-insert one-eviction limit, the don't-mutate-inside rule, inspecting eldest for pinning/logging, and how mode changes what 'eldest' means.
Articulates the policy-vs-mechanism separation behind the boolean design and the implications for custom eviction policies and invariants when extending LinkedHashMap.
## The method ```java protected boolean removeEldestEntry(Map.Entry<K,V> eldest) ``` It lives on `LinkedHashMap`. It is `protected`, so the intended use is to **subclass** LinkedHashMap and **override** it. ## When it is invoked LinkedHashMap calls `removeEldestEntry` **once at the end of every insertion** — specifically inside the internal `afterNodeInsertion` callback that runs after `put`, `putIfAbsent`, `merge`, `compute*` that *adds* a node, and each element of `putAll`. It is **not** called by `get`, `remove`, or iteration. Because it runs per single insert, it can cause **at most one eviction per insertion**. ## What 'eldest' means The argument is the **head** of the map's internal doubly-linked list — the 'oldest' entry by the map's current ordering: - **insertion-order mode (default):** the entry inserted earliest that still remains. - **access-order mode:** the **least-recently-used** entry (because accesses move entries to the tail). So the same hook builds a FIFO eviction cache in default mode or an LRU cache in access-order mode. ## What the return value does - Return **`false`** → keep everything; nothing is removed. This is the **default** implementation, which is why a plain LinkedHashMap never shrinks on its own. - Return **`true`** → LinkedHashMap **removes the eldest entry** that was passed in. You do *not* remove it yourself. ## Contract / do's and don'ts - **Do** base your decision on `size()` (e.g., `return size() > capacity;`) and/or on inspecting `eldest.getKey()/getValue()` (e.g., never evict a 'pinned' entry). - **Don't** call `remove`, `put`, or otherwise structurally modify the map inside the override — the map performs the removal itself when you return true; mutating it here risks corruption or a `ConcurrentModificationException`. - **Side effects** like logging an eviction or releasing a resource tied to `eldest` are fine, as long as they don't mutate the map. - It evicts **one** entry max per insert; if you somehow inserted in bulk and want multiple evictions, each individual insert gets its own hook call (so putAll trims incrementally). ## Why the design is shaped this way Making it a boolean *decision* function (rather than a 'doRemove' that you implement) keeps the removal logic — unlinking from the list and the bucket, updating size and modCount — inside LinkedHashMap where it is correct and consistent. Your job is only the *policy* (whether to evict), not the *mechanism*.
- Can removeEldestEntry evict more than one entry in a single put?No. It is consulted once per insertion and removes at most one (the eldest). To shrink a map that is far over budget, you need multiple inserts (or a manual trim loop); putAll trims one-per-element.
- Is it correct to call map.remove(eldest.getKey()) inside the override?No. The override is a yes/no policy decision; returning true makes LinkedHashMap remove the eldest itself. Removing manually inside the hook can corrupt internal state. You may inspect eldest or log, but not mutate the map.
saying these in an interview costs you the question
- Manually removing the entry inside the override instead of returning true.
- Believing the hook fires on get or remove — it only fires after insertions.
- Assuming it can evict many entries at once per put.
- Forgetting that 'eldest' depends on mode (insertion vs access order).