Является ли ConcurrentDictionary поточно-ориентированным, чтобы я мог использовать его для статического кэша?
Общая мысль идет по этим строкам: «Раскрывайте как можно меньше информации о внутренней работе вашего приложения для кого-либо».
Выявление идентификатора базы данных как раскрытие некоторой информации.
Причин для этого является то, что хакеры могут использовать любую информацию о ваших внутренних действиях ваших приложений, чтобы напасть на вас, или пользователь может изменить URL-адрес, чтобы попасть в базу данных, которую он / она не должен видеть?
2 ответа
Да, это потокобезопасно, и да позволяет избежать повсеместного использования блокировок (что бы это ни значило). Конечно, это обеспечит вам потокобезопасный доступ к данным, хранящимся в этом словаре, но если сами данные не являются поточно-ориентированными, то вам, конечно, нужно синхронизировать доступ к ним. Представьте, например, что вы сохранили в этом кэше List<T>. Теперь thread1 выбирает этот список (потокобезопасным способом, так как параллельный словарь гарантирует вам это), а затем начинает перечисление по этому списку. В то же самое время thread2 выбирает тот же самый список из кэша (потокобезопасным способом, поскольку параллельный словарь гарантирует вам это) и записывает в список (например, добавляет значение). Вывод: если вы не синхронизировали thread1, это приведет к проблемам.
Что касается использования его в качестве кеша, то, вероятно, это не очень хорошая идея. Для кеширования я бы порекомендовал вам то, что уже встроено в фреймворк. Классы, такие как MemoryCache , например. Причиной этого является то, что то, что встроено в сборку System.Runtime.Caching , хорошо, явно построено для кэширования => оно обрабатывает такие вещи, как автоматическое истечение срока действия данных, если у вас заканчивается нехватка памяти, обратные вызовы для кеша элементы истечения срока действия, и вы даже сможете распределить свой кэш по нескольким серверам, используя такие вещи, как memcached, AppFabric, ..., все, о чем вы не могли бы и мечтать, используя параллельный словарь.
Вам все еще может понадобиться использовать блокировку так же, как вам может потребоваться транзакция в базе данных. «Параллельная» часть означает, что словарь будет продолжать правильно работать в нескольких потоках.
В параллельную коллекцию встроены TryGetValue и TryRemove, которые подтверждают, что кто-то может удалить элемент первым. Блокировка на уровне детализации встроена, но вам все еще нужно подумать о том, что делать в этих ситуациях. Для кэширования это часто не имеет значения - то есть это идемпотентная операция.
re: кэширование. Я чувствую , что это зависит от того, что вы храните в кеше + что вы делаете с ним. Существуют затраты на кастинг, связанные с использованием объекта. Вероятно, для большинства веб-приложений лучше всего подходит MemCache, как указано выше.