并行场景下缓存消息应使用哪种线程安全集合？

直接说结论：不要裸用BlockingCollection或ConcurrentDictionary实现这个需求。这两个类型虽然单个读写操作是线程安全的，但你需要的「阈值判断→读取全量集合→清空集合」是复合原子操作，原生线程安全集合没有封装这个级别的原子逻辑，直接用会出现竞态条件：要么清空后漏了其他线程刚写入的数据，要么读出来的批量数据和清空时的实际数据不一致。

优先推荐方案：普通集合+轻量互斥锁 #

这是性能最高、逻辑最可控、最适配你当前场景的实现，没有多余的并发开销，完全能满足互斥要求：

1. 用普通的List<T>作为缓存容器即可，不需要引入重型并发集合
2. 用lock关键字把写入、阈值判断、批量提取、清空这几个逻辑包成原子操作
3. 锁内只做内存操作，拿到批量数据后立刻释放锁，再去做后续的业务处理，避免长时间阻塞写入线程

参考实现代码：

// 缓存相关常量与实例
private const int BatchFlushThreshold = 1000;
private readonly List<YourBusinessDataType> _cacheBuffer = new();
private readonly object _cacheLockObj = new();

// 并行任务调用的写入方法
public void WriteCache(YourBusinessDataType dataItem)
{
    YourBusinessDataType[] batchToProcess = null;
    lock (_cacheLockObj)
    {
        _cacheBuffer.Add(dataItem);
        // 未达到阈值直接返回，不做后续处理
        if (_cacheBuffer.Count < BatchFlushThreshold) return;

        // 原子操作：提取全量数据+清空缓存
        batchToProcess = _cacheBuffer.ToArray();
        _cacheBuffer.Clear();
    }

    // 锁外处理批量数据，不阻塞其他写入线程
    if (batchToProcess != null)
    {
        _ = ProcessBatchDataAsync(batchToProcess);
    }
}

这个方案的优势：

• 完全满足互斥要求：所有对缓存集合的操作都在互斥锁保护下，在批量提取、清空完成前，其他线程的写入请求会等待锁释放，不会出现读写穿插的问题
• 性能开销极低：lock是CLR做过深度优化的同步原语，锁内只有内存集合的Add、ToArray、Clear操作，单次锁持有时间在纳秒级，并行写入的阻塞影响可以忽略
• 维护成本低：不需要记忆各类并发集合的特殊行为边界，后续调整阈值、增加去重逻辑、加批量大小校验都可以直接修改，不容易出隐蔽的并发bug

可选扩展方案：使用Channel做异步生产消费 #

如果你后续需要扩展更复杂的流量控制逻辑（比如写入速度超过处理速度时限流、固定后台线程独立消费批量数据、支持异步等待无阻塞写入），可以用.NET Core 3.0+内置的Channel<T>组件，它是专门为异步生产者消费者场景设计的，比BlockingCollection更适配现代ASP.NET Core的异步编程模型，你可以配置批量拉取逻辑，攒够1000条或者等待超时就取出一批数据处理，不需要自己写锁逻辑。但如果只是满足当前的需求，上面的lock方案已经足够简单稳定，没必要引入额外复杂度。

避坑提醒 #

• 不要在锁内部执行数据库写入、接口调用、文件IO这类耗时操作，否则会阻塞所有并行写入的任务，严重影响服务吞吐量
• 不要为了追求“无锁”强行用ConcurrentDictionary/BlockingCollection拼接复合逻辑，这类集合的线程安全保证只覆盖单步调用，多步操作组合时一样需要加锁，反而比普通集合加锁的开销更高
• 服务停止时记得在托管服务的停止生命周期方法里加一次锁判断，把缓存里剩余不足1000条的数据取出处理，避免数据丢失

内容的提问来源于stack exchange，提问作者Julien Martin