LRU Cache with LinkedHashMap

Direct Answer

For a small, single-threaded bounded LRU map, create a LinkedHashMap with accessOrder=true and override removeEldestEntry() to evict when size() exceeds the limit. This demonstrates the policy, but it is not a complete production cache: it is not thread-safe and has no expiry, loading, statistics, or weighted eviction.

Code Example

Extend LinkedHashMap, pass accessOrder=true to the constructor, and override removeEldestEntry to evict once you exceed capacity.

import java.util.LinkedHashMap;
import java.util.Map;

class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int capacity;

    public LRUCache(int capacity) {
        super(capacity, 0.75f, true);  // accessOrder=true is the key line
        this.capacity = capacity;
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        return size() > capacity;  // evict when over capacity
    }
}

var cache = new LRUCache<String, String>(3);
cache.put("user:1", "Alice");
cache.put("user:2", "Bob");
cache.put("user:3", "Charlie");
cache.get("user:1");            // moves user:1 to the end (most recent)
cache.put("user:4", "Diana");  // evicts user:2 (least recent)
System.out.println(cache.containsKey("user:2"));  // false

That's the whole cache — three setup lines and a one-line override do all the eviction work.

Common Mistakes & Pitfalls

• Forgetting the accessOrder parameter: the two-arg constructor new LinkedHashMap(capacity, loadFactor) gives insertion order, so get won't reorder and your LRU silently behaves like FIFO.
• Not overriding removeEldestEntry: the default always returns false, so nothing is ever evicted.
• Ignoring thread safety: concurrent put or get can corrupt the internal linked list, causing ConcurrentModificationException or worse.
• Misreading 'eldest': the eldest entry is the head of the access order (least recently accessed), not the one with the oldest value.