LRU Cache Eviction
Also known as: least recently used cache, lru eviction policy, lru cache eviction
LRU (Least Recently Used) eviction is a cache policy that discards the entries accessed longest ago when the cache hits its size limit, keeping hot data and dropping cold data first. It is the default strategy behind many in-app memory and disk caches.
- LRU evicts the entry accessed longest ago once the cache reaches its size or byte limit.
- Android's LruCache and iOS's NSCache both use recency-based eviction with O(1) lookups.
- Clearing an LRU cache only frees space temporarily; active apps refill it up to their ceiling.
How LRU decides what to drop
A cache holds a bounded number of entries (or bytes). When a new entry must be stored and the cache is full, an eviction policy chooses a victim to remove. LRU orders entries by last-access time and evicts the one that has gone unused the longest, on the assumption that recently used items are most likely to be used again soon.
Implementations typically combine a hash map for O(1) lookup with a doubly linked list (or access counter) that records recency. Every get or put moves the touched entry to the most-recently-used end; eviction pops from the least-recently-used end. Variants such as LFU (least frequently used) and 2Q weigh frequency instead of, or alongside, recency.
Where you meet LRU in mobile apps
On Android, LruCache in `android.util` is the standard in-memory cache (commonly sized as a fraction of the app heap), and image libraries like Glide and Coil layer an LRU memory cache over an LRU disk cache. On iOS, NSCache uses a similar cost/recency eviction model and automatically purges under memory pressure.
Because LRU caches are bounded and self-pruning, they are not the source of long-term storage bloat. The bytes that accumulate on disk usually come from caches with no eviction, oversized disk-cache budgets, or downloaded files the app never cleans up.
Why it matters for storage cleanup
Clearing an app's cache forces it to rebuild these LRU structures from scratch, so the first reload after cleanup is slower while the cache re-warms, then performance returns to normal. The reclaimed space is real but temporary, since active apps quickly refill their LRU caches up to their configured ceilings.
Cleanor surfaces this app cache and reclaimable junk files so you can free space on demand, while leaving the app's own logic to manage day-to-day eviction. Knowing a cache is LRU-bounded tells you the bigger wins are usually elsewhere, in stale downloads, duplicates, and uncapped disk caches.