Я знаю алгоритмы MRU и его обратный один наименее используемый (LRU).
Я думаю, что LRU разумно, поскольку элемент LRU означает, что он будет использоваться, по крайней мере, в будущем. Однако элемент MRU означает, что элемент может быть использован в будущем, зачем его выселять? Каков разумный сценарий?
Представьте, что вы искали детали автобусов, когда они прибыли на остановку автобуса, исходя из их номера шины (или любого другого идентификатора, который вы используете).
Несколько разумно подумать, что если вы только что видели автобус номер 36, вы вряд ли увидели бы еще один в ближайшее время, чем тот, который остановится там, где находятся другие автобусы.
Только один пример, но идея более общая: в некоторых случаях наличие "только что увиденного" является хорошим показателем того, что вы вряд ли снова увидите то же самое.
Вариант использования - это когда вы повторяете одни и те же (больше, чем кешировать) данные несколько раз, и поэтому вы не вернетесь к недавно полученным данным. 1
Я думаю, что оба ответа @Jon Skeet и @Jeremiah Willcock описывают использование MRU как способа избежать загрязнения кеша бесполезными записями.
Это работает только в том случае, если ваши API-интерфейсы кеша позволяют вам изменять политику на лету; например, на основе запроса. Установка политики кэширования на MRU в "нормальных" ситуациях, вероятно, плохая идея... потому что ваш кэш становится неэффективным, как только он заполняется.
Проблема MRU в том, что если вы получаете удар по записи, которая часто используется в "нормальном" режиме во время поиска MRU, вы в конечном итоге выбрасываете запись...
Лучшими альтернативами MRU для сканирования без загрязнения кеша являются:
Что бы это ни стоило, я не могу представить ни одного варианта использования MRU, который бы не подходил под эту общую схему.
Кстати, пример @Jon Skeet о прибытии автобусов не всегда подтверждается на практике эффектом группирования.
Если автобус опаздывает, на каждой автобусной остановке, вероятно, будет больше, чем средний человек. Автобус должен останавливаться чаще и дольше останавливаться на каждой остановке. Это замедляет опоздание автобуса.
На автобусе, который вовремя следует за последним автобусом, обычно будет меньше людей, чем в среднем на каждой остановке. (Потому что они просто идут на опоздавший автобус.) Это ускоряет следующий автобус.
Конечным результатом является то, что автобусы, как правило, собираются в кучу.
Допустим, вы кешируете места в зале для концерта, чтобы ускорить бронирование. Когда ваше приложение загружает места, удалите кешированный элемент из кеша, поскольку они больше не требуются для заявки на бронирование.
В чем разница между MRU и LIFO?
Возможно, более осязаемым примером будет медиа-сервер. Когда пользователь завершил просмотр видео (скажем, эпизод из телешоу), он, по-видимому, реже всего захотел бы посмотреть его снова. Поэтому, если вам нужно что-то выселить, выселите последний просмотренный предмет.
На практике, однако, я полагаю, что этот тип кеша обычно используется в дополнение к кешу LRU или LFU, где два кеша в тандеме позволяют вам охватывать самые разные случаи.