concurrentdictionary适用于读多写少且需键值查找的高并发场景，支持分段锁和原子操作；concurrentqueue/stack适用于生产者-消费者模型；blockingcollection封装并发集合提供阻塞能力；concurrentbag仅适合线程本地操作。
ConcurrentDictionary 适合「读多写少 + 键值查找」场景
高并发下频繁按 key 查找、偶尔增删时，ConcurrentDictionary<tkey tvalue></tkey> 是首选。它内部用分段锁（默认 31 段），比全局锁的 Dictionary + lock 吞吐高得多，且线程安全地支持 GetOrAdd、AddOrUpdate 等原子操作。
注意点：
-
Count属性不是原子的，高并发下可能不准，别用来判断空或做循环依据 - 遍历时不保证快照一致性——可能看到部分新增/删除项，也可能跳过某些项；如需强一致性，应先
ToArray()再遍历 - 不要在循环中调用
Remove或TryRemove，否则可能抛InvalidOperationException（集合被修改）
ConcurrentQueue 和 ConcurrentStack 用于「生产者-消费者」解耦
当多个线程持续入队/压栈，另一批线程持续出队/弹栈（比如任务分发、日志缓冲），优先选 ConcurrentQueue<t></t>（FIFO）或 ConcurrentStack<t></t>（LIFO）。它们无锁实现，仅靠 CAS 和内存屏障，吞吐远高于加锁的 Queue/Stack。
典型误用：
- 用
ConcurrentQueue.Count控制消费节奏——它只是近似值，且调用本身有开销；改用TryDequeue返回false表示空更可靠 - 把
ConcurrentStack当作通用容器反复遍历——它不保证遍历顺序，也不支持索引访问，仅适合“只进不出”或“只出不进”的纯栈语义 - 在
TryPeek后直接假设元素一定存在并消费——中间可能已被其他线程弹出，必须用TryPop原子获取
BlockingCollection 包装并发集合，解决「等待-唤醒」问题
BlockingCollection<t></t> 本身不是集合，而是对 IProducerConsumerCollection<t></t>（如 ConcurrentQueue）的封装，提供 Take 阻塞等待、GetConsumingEnumerable 持续消费等能力。它让生产者-消费者模型变得直观，避免手写 Monitor.Wait/Pulse。
关键配置项：
- 构造时传入容量限制（如
new BlockingCollection<int>(new ConcurrentQueue<int>(), 1000)</int></int>），超限时Add会阻塞，防止内存爆炸 -
CompleteAdding()必须显式调用，否则GetConsumingEnumerable永远不会退出 - 不要混用底层集合的原生方法（如直接调用
queue.Enqueue）和BlockingCollection的方法，会绕过容量控制和阻塞逻辑
别踩坑：ConcurrentBag 不等于「万能 List 替代品」
ConcurrentBag<t></t> 在「每个线程主要操作自己添加的元素」时性能最优（线程本地存储 + 全局共享池），但它的设计牺牲了确定性：
- 不保证任何遍历顺序（甚至每次
ToArray()结果都不同） - 没有
Contains方法，查是否存在只能遍历，O(n) 且不可靠（期间可能被其他线程移除） - 大量跨线程争用时（比如所有线程都往一个
Bag里加、再统一取），性能反而不如加锁的List，因为要频繁迁移线程本地数据到共享池
简单说：只在明确知道「添加和消费基本由同一线程完成」（如异步任务收集中间结果）时才用 ConcurrentBag；否则优先考虑 ConcurrentQueue 或 ConcurrentDictionary。
真正难处理的是混合操作——比如既要按 key 查，又要按插入顺序遍历，还要支持并发增删。这时候没有银弹，得拆成多个并发集合协作，或者引入更重的方案（如 ReaderWriterLockSlim + 普通集合），但务必实测压测验证瓶颈点在哪里。
