C#多线程读定期全量覆写场景的集合选型与线程安全咨询

你需要实现的是典型的本地热数据缓存：

• 核心工作线程高并发执行只读操作：判断元素是否存在于集合中，对延迟要求极高
• 后台任务每隔固定时间全量拉取最新数据，一次性替换整个内存集合
• 不存在对单个集合实例的元素增、删、改操作

你的初始实现代码如下：

public class LoadedData
{
    public static HashSet<string> Keys { get; set; }
}

public class CoreProcess
{
    public bool ElementExists(string key)
    {
        return LoadedData.Keys.Contains(key);
    }
}

public class BackgroundProcess
{
    public async Task LoadData()
    {
        while (true)
        {
            LoadedData.Keys = GetKeysFromDb();
            await Task.Delay(TimeSpan.FromMinutes(5));
        }
    }
}

问题解答 #

1. 该场景下是否可以直接使用普通HashSet<T>实现需求？ #

不能直接用上述原始写法，但HashSet<T>本身是这个场景下最合适的集合类型，问题出在引用的存储和更新方式，和HashSet本身无关。

.NET所有集合类型都有官方明确保证：只要集合实例不发生任何写入/结构修改，多线程并发读是100%安全的。你的场景里如果每次更新都生成全新的HashSet实例，等所有数据填充完成后再替换对外暴露的引用，旧的HashSet实例不会被任何线程修改，那么HashSet本身的多线程读不存在任何问题。但你当前用普通静态自动属性存储集合引用，没有做任何并发语义处理，会触发线程安全问题。

2. 针对该高并发读、定期全量覆写的场景，推荐使用哪种集合类型？ #

优先选择普通HashSet<T>，不需要使用BlockingCollection<T>、ConcurrentBag<T>、ConcurrentDictionary<T, byte>这类线程安全集合，也没必要使用ImmutableHashSet<T>。
原因如下：

• 上述线程安全集合都是为「多线程同时操作同一个集合实例、存在并发增删改」的场景设计的，内部自带细粒度锁、自旋等待或额外的内存屏障开销，高并发读场景下会产生不必要的性能损耗，无法满足极致响应速度的要求。
• ImmutableHashSet<T>的读性能比普通HashSet低30%以上，它的核心优势是支持增量修改后返回新副本，而你的场景是全量加载数据，完全用不上这个特性。
• 普通HashSet<T>的Contains是O(1)时间复杂度，是.NET中判断元素存在性性能最高的集合类型，只要实例不被修改，多线程读没有任何额外开销。

你只需要解决集合引用替换时的原子性、可见性问题即可，不需要更换集合类型。

3. 核心进程多线程读取集合、与后台进程全量覆写集合的操作并发执行时，是否会产生线程安全问题？ #

你贴的原始写法会产生线程安全问题，修正引用读写逻辑后可以完全规避并发问题。

原始写法的风险点有两个：

• 可见性问题：普通属性的读写没有内存屏障保证，JIT编译器可能将集合引用缓存到CPU寄存器，或者因CPU缓存一致性策略导致读线程长时间看不到后台线程更新的新引用，出现数据长期不一致。
• 引用撕裂风险：在32位运行时环境下，64位引用的赋值不是原子操作，读线程可能读到半旧半新的无效引用，直接触发空引用、内存访问违规等运行时异常。

只要做两个简单修正就能彻底解决所有线程安全问题：

• 新集合必须在后台线程中完全构造、填充完所有数据之后，再执行对外引用的替换，绝对不能把未填充完成的集合暴露给读线程。
• 用带原子读写、内存屏障语义的方式存储和更新集合引用，比如用volatile修饰存储字段、用Interlocked.Exchange执行引用替换、读操作时先用Volatile.Read拿到当前稳定的集合引用。

修正后的实现代码如下：

public static class LoadedData
{
    // volatile修饰禁止JIT/CPU对字段读写做缓存、重排
    private static volatile HashSet<string> _keys = new HashSet<string>();

    public static HashSet<string> Keys => _keys;

    /// <summary>
    /// 后台更新集合入口
    /// </summary>
    public static void ReplaceKeys(HashSet<string> newKeys)
    {
        // 原子替换引用，保证所有线程立刻可见新值
        Interlocked.Exchange(ref _keys, newKeys);
    }
}

public class CoreProcess
{
    public bool ElementExists(string key)
    {
        // 先拿到当前时刻的稳定引用，避免执行Contains过程中引用被替换（替换不影响，拿到的旧实例始终是只读的）
        var currentKeys = Volatile.Read(ref LoadedData.Keys);
        return currentKeys.Contains(key);
    }
}

public class BackgroundProcess
{
    public async Task LoadData()
    {
        while (true)
        {
            // 新集合在本地构造，构造过程无其他线程访问，无并发问题
            var newKeys = FetchKeysFromDatabase();
            // 构造完成后一次性替换对外引用
            LoadedData.ReplaceKeys(newKeys);
            await Task.Delay(TimeSpan.FromMinutes(5));
        }
    }

    private HashSet<string> FetchKeysFromDatabase()
    {
        // 实现从数据库拉取全量数据、填充到新HashSet的逻辑
        return new HashSet<string>();
    }
}

这种实现下，读线程要么拿到旧集合的引用（旧集合始终处于只读状态，多线程读完全安全），要么拿到已经构造完成的新集合引用，不存在中间状态，没有任何锁开销，读性能和单线程场景下的HashSet读基本一致，是该场景下的最优方案。

内容的提问来源于stack exchange，提问作者Alex Nevajniy