如何安全释放WaitHandle？多线程场景下的竞态风险探讨

阿华AIGC实验室

2026-5-9

问题分析与解决方案

首先明确回答你的核心疑问：是的，这种场景存在潜在的竞态条件和未定义行为，必须妥善处理。

为什么会有风险？

你已经挖到了问题的本质：Set()最终调用Win32的SetEvent，Close()最终调用CloseHandle，这两个Win32 API之间没有任何同步机制。如果CloseHandle先执行，后续Thread1调用SetEvent操作一个已经被关闭的句柄，这属于Win32 API层面的未定义行为——可能会返回ERROR_INVALID_HANDLE错误，极端情况下甚至可能触发进程级别的异常（虽然概率不高，但风险不可忽视）。

原代码里的volatile和空合并运算符只能保证对waitHandle托管引用的原子访问，但管不到底层句柄资源的并发操作，这是两个完全不同的层面。

正确的处理方式

针对这个场景，有几种靠谱的解决方案，你可以根据实际业务场景选择：

1. 用同步锁保护句柄的生命周期

虽然看起来像是“用同步机制包裹同步机制”，但这是合理的——我们要保护的是底层句柄的操作原子性，而不是托管对象的引用。修改后的代码示例：

private readonly object _handleSyncLock = new object();
volatile EventWaitHandle waitHandle;

// Thread1（IO绑定工作线程）
while (true) 
{
    lock (_handleSyncLock)
    {
        waitHandle?.Set();
    }
    // 加个小延迟避免空转占用过多CPU
    Thread.Sleep(1);
}

// Thread2（主线程）
waitHandle = new AutoResetEvent(true);
waitHandle.WaitOne();
Thread.Sleep(1000); // 模拟工作负载

// 安全关闭等待句柄
lock (_handleSyncLock)
{
    EventWaitHandle handle = waitHandle;
    waitHandle = null;
    handle?.Close();
}

通过同一个锁包裹Set()和Close()操作，确保两者不会并发执行，从根本上消除竞态。

2. 优雅终止工作线程后再关闭句柄

如果Thread1是可控的（比如你能管理它的生命周期），可以引入取消令牌让Thread1主动停止调用Set()，之后再安全关闭句柄，示例：

private CancellationTokenSource _workerCts = new CancellationTokenSource();
volatile EventWaitHandle waitHandle;
Thread workerThread;

// 启动Thread1
workerThread = new Thread(() => {
    while (!_workerCts.Token.IsCancellationRequested)
    {
        waitHandle?.Set();
        Thread.Sleep(1);
    }
}) { IsBackground = true };
workerThread.Start();

// Thread2（主线程）逻辑
waitHandle = new AutoResetEvent(true);
waitHandle.WaitOne();
Thread.Sleep(1000); // 模拟工作负载

// 先请求工作线程停止
_workerCts.Cancel();
// 等待工作线程退出（如果是后台线程可以跳过，但确保安全最好等）
workerThread.Join();

// 现在可以安全关闭句柄了
EventWaitHandle handle = waitHandle;
waitHandle = null;
handle?.Close();

这种方式更优雅，从根源上避免了对已关闭句柄的操作。