【问题标题】:Why does cache use Most Recently Used (MRU) algorithm as evict policy?为什么缓存使用最近使用(MRU)算法作为驱逐策略?
【发布时间】:2011-07-02 13:37:41
【问题描述】:

我知道 MRU 的算法及其逆向最近最少使用 (LRU)。

我认为 LRU 是合理的,因为 LRU 元素意味着将来至少有可能使用它。但是,MRU 元素意味着该元素将来很有可能被使用,为什么要驱逐它呢?合理的场景是什么?

【问题讨论】:

    标签: java algorithm caching


    【解决方案1】:

    假设您正在根据公交车号(或您使用的任何标识符)查找公交车到达公交车站时的详细信息。

    如果您刚刚看到一辆 36 路公交车,您不太可能立即看到另一辆公交车,而不是看到一辆其他停在那里的巴士。

    只是一个例子,但这个想法更笼统:在某些情况下,“刚刚看到某物”是一个很好的指标,表明您不太可能很快再次看到相同的东西。 p>

    【讨论】:

    • 现在在坐公交车:)?
    • @Petar:碰巧,我现在是,但我在写这篇文章时正在火车上 :)
    • @JonSkeet 这不违反时间局部性原则吗?
    • @shingaridavesh:你到底是什么意思?
    • @shingaridavesh:是的 - 你错过了一个事实,即并非所有情况都是相同的。有时您更有可能很快再次使用相同的值,而有时您不太可能这样做。这就是为什么同时存在 MRU 和 LRU 算法的原因 - 因此您可以选择最适合您情况的算法。
    【解决方案2】:

    也许更具体的例子是媒体服务器。当用户完成观看视频(假设它是电视节目的一集)时,他们可能最不想再次观看它。因此,如果您必须驱逐某些内容,请驱逐最近查看的项目。

    不过,在实践中,我相信这种类型的缓存通常与 LRU 或 LFU 缓存一起使用,这两种缓存的串联允许您涵盖各种情况。

    【讨论】:

      【解决方案3】:

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

      1. 这仅在您的缓存 API 允许您动态更改策略时才有效;例如根据每个请求。在“正常”情况下将缓存策略设置为 MRU 可能是个坏主意……因为缓存一旦填满就会失效。

      2. MRU 的问题是,如果您在查找 MRU 时经常在“正常”模式下使用的条目被点击,您最终会丢弃该条目......

      在不污染缓存的情况下进行扫描的 MRU 更好的替代方法是:

      • 完全绕过缓存,
      • 在不进行读取/更新且不更改 LRU 链的情况下探测缓存。

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


      顺便说一下,@Jon Skeet 的公交车到站示例由于聚束效应在现实中并不总是得到证实。

      • 如果公交车晚点,在每个公交车站等候的人可能会多于普通人。公共汽车必须更频繁地停靠,并且在每一站停留的时间更长。这会减慢晚班车的速度。

      • 一辆准时跟随晚点巴士的巴士通常比每个巴士站的平均等候人数要少。 (因为他们只是上了迟到的巴士。)这加快了后面的巴士。

      • 最终结果是公共汽车往往会挤在一起。

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

      【讨论】:

        【解决方案4】:

        用例是当您多次迭代相同(大于缓存)的数据时,您将不会返回最近访问的数据。1

        【讨论】:

          【解决方案5】:

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

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            • 2011-05-11
            • 1970-01-01
            • 1970-01-01
            • 2017-07-26
            • 1970-01-01
            • 2020-10-02
            相关资源
            最近更新 更多