c# 如何安全地从多线程环境调用非线程安全的代码

来源：这里教程网时间：2026-02-21 17:40:26 作者：

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

非线程安全的代码（比如某些旧版

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<t></t>
接收任务，顺序执行 TaskScheduler：创建单线程调度器（
new ConcurrentExclusiveSchedulerPair().ExclusiveScheduler
），投递
Task
运行

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

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