AutoResetEvent 阻塞失效的根本原因是其“自动重置”机制：每次 Set() 仅唤醒一个线程且立即将状态重置为 false，多次 Set() 未被 WaitOne() 匹配时信号会丢失；必须确保 Set() 与 WaitOne() 次数基本匹配，避免误用于广播场景。
AutoResetEvent 为什么总不按预期阻塞线程
根本原因不是 AutoResetEvent 用错了，而是没理解它的“自动重置”行为：每次 Set() 只唤醒一个等待线程，且内部状态**立即回到未触发（false）**。如果你在唤醒前多次调用 Set()，后几次会直接丢弃——它不像信号量那样累积。
典型误用场景：多个线程同时 WaitOne()，你却只调一次 Set()，结果只有一个线程继续；或者你在循环里反复 Set() 但没对应足够多的 WaitOne()，导致信号丢失。
- 必须保证
WaitOne()和Set()的调用次数基本匹配，尤其在生产者-消费者模型中 - 不要用
AutoResetEvent实现“广播”需求，该用ManualResetEvent - 初始化时传
true表示初始已触发，但首次WaitOne()不阻塞，之后仍自动重置——这点常被忽略
WaitOne() 超时和取消怎么配合 CancellationToken
WaitOne() 本身不接受 CancellationToken，但可以组合使用：用带超时的重载 + 循环轮询 + 外部取消检查。硬上 WaitOne(int) 并不可靠，因为超时后你得自己判断是“真超时”还是“只是没等到信号”。
更稳妥的做法是把 AutoResetEvent 和 CancellationToken.Register() 结合，在取消时主动 Set()，让等待线程能及时退出：
var ev = new AutoResetEvent(false);
var cts = new CancellationTokenSource();
// 注册取消回调：触发事件，使 WaitOne 退出
cts.Token.Register(() => ev.Set());
// 等待事件或取消
if (!ev.WaitOne(5000)) {
if (cts.Token.IsCancellationRequested) {
// 真正取消了
} else {
// 超时了
}
}
- 别依赖
WaitOne(TimeSpan)返回false就认定超时——如果期间被取消，它也可能返回false - 注册的
Register()回调在取消时执行，但不保证立即执行；若需强实时响应，仍建议加短超时+轮询 - 注意
Register()返回的Disposable，应在适当时候释放（比如using或显式Dispose()）
AutoResetEvent 在 async/await 场景下不能直接 await
AutoResetEvent 是同步原语，没有内置的 Task-based 异步方法。直接写 await ev.WaitOne() 会编译失败——它根本没有 GetAwaiter() 方法。
强行异步化有风险：用 Task.Run(() => ev.WaitOne()) 会把线程池线程卡住，违背 async/await 减少线程占用的初衷。正确做法是用 TaskCompletionSource<bool></bool> 封装：
private static Task WaitAsync(AutoResetEvent ev, CancellationToken ct = default) {
var tcs = new TaskCompletionSource<bool>();
ct.Register(() => tcs.TrySetCanceled());
var registration = new Action(() => tcs.TrySetResult(true));
ev.Set(); // 防止注册前已触发（可选）
ThreadPool.UnsafeQueueUserWorkItem(_ => {
ev.WaitOne();
registration();
}, null);
return tcs.Task;
}
- 上面只是示意逻辑，实际推荐用现成库如
Microsoft.Threading.Tasks中的扩展，或直接迁移到AsyncManualResetEvent（来自Microsoft.VisualStudio.Threading） - 千万不要在 ASP.NET Core 请求线程中用
WaitOne()，极易引发线程饥饿 - 如果只是等 I/O 完成，优先用原生异步 API（如
Stream.ReadAsync），而非绕路用同步事件
Dispose() 忘记调用会导致什么
AutoResetEvent 包装的是 Windows 内核对象（Event handle），不调用 Dispose() 会泄漏句柄。在长期运行服务中，句柄耗尽后会出现 System.ComponentModel.Win32Exception: 找不到资源 或 Unable to create WaitHandle 类错误。
- 必须确保每个
new AutoResetEvent(...)都有对应的Dispose()，最好用using语句 - 跨线程共享时，要约定好谁负责释放——通常是创建者，而不是最后一个等待者
- 在 .NET 6+ 中，若对象被 GC 回收前未
Dispose()，终结器会尝试清理，但不保证及时，且可能抛异常（尤其在进程退出时）
最麻烦的情况是把它作为类字段长期持有，又没在 IDisposable 实现里释放——这种泄漏往往要压测几天才暴露。
