C#: Как реализовать интеллектуальный кеш

Question

У меня есть места, где реализация какого-то кеша может быть полезна. Например, в случаях выполнения поиска ресурсов на основе пользовательских строк, поиска имен свойств с использованием отражения или наличия только одного PropertyChangedEventArgs для каждого имени свойства.

Простой пример последнего:

public static class Cache 
{ 
    private static Dictionary<string, PropertyChangedEventArgs> cache; 
    static Cache() 
    { 
     cache = new Dictionary<string, PropertyChangedEventArgs>(); 
    } 
    public static PropertyChangedEventArgs GetPropertyChangedEventArgs(
     string propertyName) 
    { 
     if (cache.ContainsKey(propertyName)) 
      return cache[propertyName]; 

     return cache[propertyName] = new PropertyChangedEventArgs(propertyName); 
    } 
} 

Но это будет работать хорошо? Например, если бы у нас была вся загрузка разных имен свойств, это означало бы, что у нас будет огромный кеш, в котором никогда не будет сбора мусора или чего-то еще. Я представляю, что то, что кэшируется, - это большие значения, и если приложение является долговременным, это может стать проблемой ... или что вы думаете? Как должен быть реализован хороший кеш? Является ли это достаточно хорошим для большинства целей? Любые примеры некоторых хороших реализаций кэша, которые не так сложно понять или слишком сложно реализовать?

Answer 1

Вы можете обернуть каждый из ваших кешированных предметов в WeakReference. Это позволило бы GC вернуть элементы в случае необходимости и, если это необходимо, однако не дает вам какого-либо подробного контроля за тем, когда элементы исчезнут из кеша, или вы сможете реализовать явные политики истечения срока действия и т. Д.

(Ha Я просто заметил, что пример, приведенный на MSDN page, является простым классом кеширования.)

Answer 2

Это хорошая дискуссия, чтобы иметь, но в зависимости от вашего приложения, вот несколько советов:

Вы должны определить размер максимального кэша, что делать со старыми пунктами, если ваш кэш заполнен, есть продувка стратегии, определить время жизни объекта в кеше, ваш кеш может/должен сохраняться где-то еще в этой памяти, в случае ненормального завершения приложения, ...

Answer 3

Это большая проблема, вам нужно определить область проблемы и применить правильные методы. Например, как бы вы описали истечение срока действия объектов? Застывают ли они за определенный промежуток времени? Неужели они устаревают от внешнего события? Как часто это происходит? Кроме того, сколько у вас объектов? Наконец, сколько стоит генерировать объект?

Простейшей стратегией было бы сделать прямую memoization, как вы уже выше. Это предполагает, что объекты никогда не истекают, и что не так много, чтобы запустить вашу память сухим и, что вы считаете, что затраты на создание этих объектов требуют использования кеша для начала.

Следующий слой может состоять в том, чтобы ограничить количество объектов и использовать неявную политику истечения срока действия, такую ​​как LRU (последнее время используется). Для этого вы обычно используете двойной список в дополнение к вашему словарю, и каждый раз, когда объекты обращаются к нему, он перемещается в начало списка. Затем, если вам нужно добавить новый объект, но он превышает ваш предел общих объектов, вы должны удалить его из задней части списка.

Далее вам может потребоваться принудительное явное истечение, основанное на времени или внешнем стимуле. Это потребует, чтобы у вас было какое-то событие истечения срока действия, которое можно было бы назвать.

Как вы можете видеть, в кешировании много дизайна, поэтому вам нужно правильно понимать свой домен и инженер. Я не понял подробностей, чтобы обсудить специфику.

P.S. Пожалуйста, подумайте об использовании Generics при определении вашего класса, чтобы можно было хранить многие типы объектов, что позволяет повторно использовать код кэширования.

Answer 4

Это распространенная проблема, которая имеет множество решений в зависимости от потребностей вашего приложения. Общеизвестно, что Microsoft выпустила целую библиотеку для ее решения. Вы должны проверить Microsoft Velocity, прежде чем сворачивать свой собственный кеш. http://msdn.microsoft.com/en-us/data/cc655792.aspx Надеюсь, что эта помощь.

Answer 5

Вы можете использовать WeakReference, но если ваш объект не такой большой, как нет, потому что WeakReference будет занимать больше памяти, чем сам объект, что не является хорошей техникой. Кроме того, если объект является кратковременным использованием, когда он никогда не сделает его поколением 1 из поколения 0 на GC, нет необходимости в WeakReference, но интерфейс IDisposable на объекте будет иметь с выпуском SuppressFinalize.

Если вы хотите контролировать время жизни, вам нужен таймер, чтобы обновить datetime/timespan снова значение targetExpirationTime для объекта в вашем кеше.

Важно, если объект большой, тогда выберите, чтобы WeakReference else использовал сильную ссылку. Кроме того, вы можете установить емкость в словаре и создать очередь для запроса дополнительных объектов в вашем буфере temp, который сериализует объект и загружает его, когда в словаре есть место, затем очистите его из каталога temp.

Answer 6

Похоже, что .NET 4.0 теперь поддерживает System.Runtime.Caching для кеширования многих типов вещей. Вы должны сначала изучить это, вместо того, чтобы повторно изобретать колесо. Подробнее:

http://msdn.microsoft.com/en-us/library/system.runtime.caching%28VS.100%29.aspx