为何LRU更适用于缓冲缓存文件缓冲区替换，却不适用于页面置换算法？

Great questions—these get to the heart of how cache algorithms behave in different system contexts. Let’s break them down clearly, focusing on the access patterns and tradeoffs that make LRU a star for file buffers but a tricky fit for page replacement.

LRU (Least Recently Used) excels here because it aligns perfectly with how we actually use files:

• Matches strong access locality: Most file operations follow locality of reference—you’ll repeatedly read a config file, stream a video in sequential blocks, or edit the same document for hours. LRU’s rule (evict the block that’s gone untouched the longest) keeps the blocks you’re actively using (or likely to use next) in fast memory, skipping slow disk reads.
• Captures clear "hot" file blocks: File systems have obvious hotspots—system libraries, frequently edited docs, or log files get way more traffic than random, one-off files. LRU holds onto these hot blocks because every access bumps them to the "most recently used" end of the cache, so they’re never the first to get evicted.
• Low overhead for practical gains: Tracking LRU (via a linked list that updates when a block is accessed) is a tiny cost compared to the massive savings of avoiding disk I/O. File buffer accesses are less frequent and more focused than page accesses, so this overhead never becomes a bottleneck.

The gap comes down to fundamental differences between page and file buffer usage:

• Unpredictable, bursty page access patterns: Processes have huge virtual address spaces, and page accesses can be chaotic. Imagine a batch job scanning millions of pages once—this pushes all your frequently used app pages to the LRU tail and evicts them. When your app needs those pages again, you get a flood of page faults (called thrashing) that grinds performance to a halt. File buffers almost never face this: you’re unlikely to access thousands of unique file blocks in a single burst that overwhelms the cache.
• Higher tracking overhead for pages: Every page access requires updating the LRU order, which adds up when you’ve got thousands of processes hitting millions of pages. This constant list manipulation becomes a performance drain. File buffers, by contrast, have far fewer active blocks at any time, so the tracking cost is negligible.
• Better alternatives exist for pages: Algorithms like Clock (NRU) or WSClock skip full LRU tracking—they use a simple "use bit" to approximate recent usage. These are lighter on system resources and better at handling transient bursts, trading perfect accuracy for real-world performance. For file buffers, though, LRU’s accuracy is worth the small overhead because it reliably keeps critical hot files in cache.

内容的提问来源于stack exchange，提问作者Sarah