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+ 普通集合），但务必实测压测验证瓶颈点在哪里。
