首先得说，你踩的这两个坑其实是同步原语使用中的典型误区——咱们一步步拆解问题，再给你一个靠谱的实现方案。

为什么加lock会导致死锁？ #

你在StartingMethod里用lock (_lockObject)包裹_pauseEvent.WaitOne()的时候，相当于持有锁的线程进入了阻塞状态：

• 后台线程拿着_lockObject，卡在WaitOne()上等待事件信号；
• 此时点击暂停/恢复按钮，对应的Task.Run线程会尝试获取_lockObject，但锁已经被后台线程攥着不放；
• 按钮线程拿不到锁就没法修改_pauseEvent的状态，后台线程又因为等不到信号一直占着锁——死锁就这么产生了。

而且更关键的是：ManualResetEvent的Reset和Set方法本身就是线程安全的，微软设计这些同步原语的时候就已经处理了多线程并发调用的问题，你额外加的锁完全是画蛇添足。

那原来的句柄无效问题是怎么回事？ #

你遇到的“句柄无效”错误，大概率和竞态条件无关，更可能是这些原因：

• 代码里不小心调用了_pauseEvent.Dispose()，提前释放了内核句柄；
• 全局的_pauseEvent被意外重新赋值（比如某个地方又new了一个），旧的句柄自然失效；
• 极少数情况下是系统资源回收导致，但这种情况极少见，通常是资源管理不当引发的。

修正后的完整实现方案 #

我给你调整一下代码，用更轻量的ManualResetEventSlim（适合短时间等待场景，性能更好，还能减少句柄相关问题），同时避开死锁和无效句柄的坑：

1. 全局字段定义

// 初始化为Set状态，启动时不阻塞线程
private readonly ManualResetEventSlim _pauseEvent = new ManualResetEventSlim(true);
// 标记是否正在运行，防止重复点击启动
private bool _isRunning;
// 保护_isRunning的线程安全访问
private readonly object _stateLock = new object();

2. 启动按钮点击事件

private async void btnStart_Click(object sender, EventArgs e)
{
    // 线程安全地检查并设置运行状态
    lock (_stateLock)
    {
        if (_isRunning) return;
        _isRunning = true;
    }

    try
    {
        // 只把真正耗时的逻辑放到后台线程
        await Task.Run(() => StartingMethod());
    }
    finally
    {
        lock (_stateLock)
        {
            _isRunning = false;
            // 恢复事件状态，避免下次启动时处于暂停状态
            _pauseEvent.Set();
        }
    }
}

3. 暂停/恢复按钮点击事件

private void btnPause_Click(object sender, EventArgs e)
{
    // Reset是轻量操作，直接在UI线程调用即可，线程安全
    _pauseEvent.Reset();
}

private void btnResume_Click(object sender, EventArgs e)
{
    // Set同理，无需放到Task.Run里
    _pauseEvent.Set();
}

4. 耗时操作方法

private void StartingMethod()
{
    for (int i = 0; i < 1000000; i++)
    {
        // 等待事件信号，支持暂停
        _pauseEvent.Wait();

        // 这里替换成你的实际耗时操作
        // 示例：模拟耗时工作
        Thread.Sleep(10);

        // 可选：如果需要支持取消，可以添加CancellationToken检查
        // _cancellationToken.ThrowIfCancellationRequested();
    }
}

关键注意事项 #

1. 别给同步原语加多余的锁：像ManualResetEvent、Semaphore这类同步工具本身就是线程安全的，额外加锁只会引发死锁；
2. 避免持有锁时调用阻塞方法：这是死锁的高频诱因，一定要让锁的持有时间尽可能短；
3. 轻量同步操作别放Task.Run：Reset/Set这类操作耗时可以忽略，直接在UI线程执行即可，减少线程切换开销；
4. 用ManualResetEventSlim替代ManualResetEvent：它在短等待场景下用自旋锁，不需要创建内核句柄，资源占用更低，也更少出现句柄相关问题。

内容的提问来源于stack exchange，提问作者Inside Man