Когда мне следует использовать ConcurrentDictionary и Dictionary?

Используйте ConcurrentDictionary, если вы часто используете свой словарь в коде, это своего рода расплывчатый совет. Я не виню вас в путанице.

ConcurrentDictionary в первую очередь предназначен для использования в среде, где вы обновляете словарь из нескольких потоков (или асинхронных задач). Вы можете использовать стандартный Dictionary из любого количества кода, если он из одного потока;)

Если вы посмотрите на методы в ConcurrentDictionary, вы обнаружите некоторые интересные методы, такие как TryAdd, TryGetValue, TryUpdate и TryRemove.

Например, рассмотрим типичный шаблон, который вы можете увидеть при работе с обычным Dictionary классом.

// There are better ways to do this... but we need an example ;)
if (!dictionary.ContainsKey(id))
    dictionary.Add(id, value);

Проблема заключается в том, что между проверкой наличия ключа и вызовом Add другой поток может вызвать Add с тем же id. Когда этот поток вызывает Add, он генерирует исключение. Метод TryAdd обрабатывает это за вас и возвращает истину / ложь, сообщая вам, добавил ли он его (или этот ключ уже был в словаре).

Поэтому, если вы не работаете в многопоточном разделе кода, вы, вероятно, можете просто использовать стандартный класс Dictionary. При этом теоретически у вас могут быть блокировки для предотвращения одновременного доступа к словарю; этот вопрос уже рассмотрен в Блокировка словаря по сравнению с ConcurrentDictionary.

ConcurrentDictionary полезен, когда вам нужно получить доступ к словарю через несколько потоков (например, многопоточность). Объекты Vanilla Dictionary не обладают этой возможностью и поэтому должны использоваться только в однопоточном режиме.

Самая большая причина использовать ConcurrentDictionary вместо обычного Dictionary - это безопасность потоков. Если ваше приложение будет получать несколько потоков, использующих один и тот же словарь одновременно, вам понадобится потокобезопасный ConcurrentDictionary, это особенно верно, когда эти потоки записывают или создают словарь.

Обратной стороной использования ConcurrentDictionary без многопоточности являются накладные расходы. Все те функции, которые позволяют ему быть потокобезопасным, по-прежнему будут там, все блокировки и проверки будут по-прежнему выполняться, требуя времени на обработку и использования дополнительной памяти.

ConcurrentDictionary полезен, когда вам нужен высокопроизводительный словарь, к которому могут безопасно обращаться одновременно несколько потоков. По сравнению со стандартным Dictionary, защищенным с помощью lock, он более эффективен при интенсивном использовании из-за его реализации гранулярной блокировки. Вместо того, чтобы все потоки конкурировали за одну блокировку, ConcurrentDictionary поддерживает несколько блокировок внутри, минимизируя таким образом конкуренцию и ограничивая возможность стать узким местом.

Несмотря на эти приятные характеристики, количество сценариев, в которых использование ConcurrentDictionary является лучшим вариантом, на самом деле довольно мало. На то есть две причины:

1. Гарантии безопасности потоков, предлагаемые ConcurrentDictionary, ограничиваются защитой его внутреннего состояния. Вот и все. Если вы хотите сделать что-нибудь немного нетривиальное, например, обновить словарь и другую переменную как атомарную операцию, вам не повезло. Этот сценарий не поддерживается для ConcurrentDictionary. Даже защита содержащихся в нем элементов (в случае, если они являются изменяемыми объектами) не поддерживается. Если вы попытаетесь обновить одно из его значений с помощью _ 8_, словарь будет защищен, а значение - нет. Update в этом контексте означает замену существующего значения другим, а не изменение существующего значения.

2. Всякий раз, когда вы находите соблазн использовать ConcurrentDictionary, обычно доступны лучшие альтернативы. Альтернативы, не связанные с общим состоянием, чем, по сути, является ConcurrentDictionary. Независимо от того, насколько эффективна его схема блокировки, ему будет сложно превзойти архитектуру, в которой вообще нет общего состояния, и каждый поток выполняет свои функции, не мешая другим потокам. Обычно используемые библиотеки, которые следуют этому принципу, - это PLINQ и TPL Dataflow библиотека. Ниже приведен пример PLINQ:

Dictionary<string, Product> dictionary = productIDs
    .AsParallel()
    .Select(id => GetProduct(id))
    .ToDictionary(product => product.Barcode);

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

Принятый выше ответ правильный. Тем не менее, стоит упомянуть явно, если словарь не изменяется, то есть он только когда-либо читается, независимо от количества потоков, тогда Dictionary<TKey,TValue> предпочтительнее, потому что синхронизация не требуется.

например конфигурация кэширования в Dictionary<TKey,TValue>, который заполняется только один раз при запуске и используется во всем приложении на протяжении всего жизненного цикла приложения.

Когда использовать поточно-ориентированную коллекцию: ConcurrentDictionary или Dictionary

Если вы читаете только ключ или значения, Dictionary ‹TKey, TValue› работает быстрее, потому что не требуется синхронизации, если словарь не изменяется никакими потоками.