为什么缓存使用最近使用（MRU）算法作为逐出策略？

Question

我知道MRU的算法及其反向最近最少使用（LRU）。

我认为LRU是合理的，因为LRU元素意味着它将来至少可以使用。但是，MRU元素意味着将来很有可能使用该元素，为什么要逐出它？什么是合理的情况？

Answer 1

想象一下，当他们到达公共汽车站时，根据他们的公交车号码（或您使用的任何标识符）查看公交车的详细信息。

考虑到如果你刚刚看到36号公共汽车，你不太可能看到另一辆公共汽车，而不是看到停在那里的其他公共汽车。

只是一个例子，但这个想法更为笼统：在某些情况下，“只是看到一些东西”是一个很好的指标，你很快就不会再看到同样的东西了。

Answer 2

用例是当您多次迭代相同（大于缓存）数据时，因此您将不会返回最近访问过的数据.1

Answer 3

我认为@Jon Skeet和@Jeremiah Willcock的答案都在描述使用MRU作为一种避免使用无用条目来缓存缓存的方法。

1. 这仅适用于缓存API允许您即时更改策略的情况;例如在每个请求的基础上。在“正常”情况下将缓存策略设置为MRU可能是个坏主意...因为缓存在填满后会变得无效。
2. MRU存在的问题是，如果您在执行MRU查找时经常在“正常”模式下使用的条目上命中，您最终会丢弃该条目...

在不污染缓存的情况下进行扫描的更好的MRI替代方案是：

• 完全绕过缓存，
• 探测缓存而不进行读取/更新，也不改变LRU链。

---

对于它的价值，我想不出任何不符合这种一般模式的MRU用例。

---

顺便提一下，由于聚集效应，@ Jon Skeet的公交车到达的例子并不总是在现实中得到证实。

• 如果公共汽车迟到，每个公共汽车站的人数可能会超过普通人。公交车必须更频繁地停车，并在每个站点停留更长时间。这减缓了晚班车的速度。
• 在晚班车之后准时的公交车通常比每个公交车站的平均等候人数少。 （因为他们只是去了晚班车。）这加快了后面的公共汽车。
• 最终的结果是公共汽车往往堆积如山。

见：https://en.wikipedia.org/wiki/Bus_bunching

Answer 4

假设您正在为音乐会缓存大厅的座位，以加快预订。当您的应用程序预订座位时，请从缓存中删除缓存的项目，因为预订应用程序不再需要它们。