C# 多线程调用非线程安全代码的正确方法

非线程安全代码在多线程下并发访问会因竞争条件导致数据错乱、异常或静默损坏；应通过lock保护临界区、改用Concurrent集合，或隔离到单线程上下文执行。

为什么直接调用非线程安全代码会出问题

非线程安全的代码（比如某些旧版 System.Drawing 类、自定义的共享 Dictionary 实例、或未加锁的静态缓存）在多线程下被并发访问时，可能引发数据错乱、NullReferenceException、InvalidOperationException，甚至静默损坏状态。这不是“偶尔报错”，而是竞争条件（race condition）——结果不可预测，且难以复现。

用 lock 保护临界区是最直接的方式

当你要调用的非线程安全逻辑是短时、确定、且可识别边界的（例如更新一个共享计数器、写入一个全局日志缓冲区），用 lock 是最可控的选择。关键是锁对象必须唯一、私有、不可被外部修改。

• 不要锁 this、typeof(MyClass) 或字符串字面量——它们可能被其他代码共用，导致意外阻塞或死锁
• 推荐声明一个 private readonly object _syncRoot = new object(); 作为锁对象
• 确保所有访问该共享资源的路径都经过同一把锁，包括读和写

private readonly object _syncRoot = new object();
private int _sharedCounter;

public void IncrementCounter()
{
    lock (_syncRoot)
    {
        _sharedCounter++; // 非线程安全操作，现在受保护
    }
}

用 ConcurrentQueue / ConcurrentDictionary 替代手写同步逻辑

如果你原本想用锁来保护一个集合操作（如“先查再删”、“如果不存在则添加”），直接换成 Concurrent* 类型通常更安全、更高效。它们内部使用细粒度锁或无锁算法，避免了你手动同步的疏漏。

• ConcurrentDictionary.TryAdd(key, value) 比 “先 ContainsKey 再 Add” 更可靠
• ConcurrentQueue.TryDequeue(out T item) 不会因队列为空抛异常，也无需额外 lock
• 注意：ConcurrentDictionary 的 Count 属性不是原子的，遍历时仍需考虑迭代期间的变更

把非线程安全代码移到单线程上下文中执行

当非线程安全逻辑较重、或依赖不可重入的外部资源（如 COM 组件、某些 Win32 GDI 句柄），强行加锁反而容易引发死锁或 UI 响应问题。这时更适合把它“隔离”到一个明确的单线程环境：

• UI 线程：WPF/WinForms 中用 Dispatcher.Invoke 或 Control.Invoke
• 专用后台线程：启动一个长期运行的 Thread，用 BlockingCollection 接收任务，顺序执行
• TaskScheduler：创建单线程调度器（new ConcurrentExclusiveSchedulerPair().ExclusiveScheduler），投递 Task 运行

这种方式牺牲一点吞吐，但彻底规避了同步复杂度——尤其适合封装成服务类，对外提供异步接口，内部自动序列化调用。

真正难的不是选哪种方案，而是识别“哪里不安全”：有些类文档没写线程安全性，有些方法看似只读却偷偷改了内部缓存。遇到不确定的第三方库，宁可默认按非线程安全处理，加一层隔离，也别赌它“应该没问题”。