Mutex、Semaphore等4个系统级同步原语原理与实战

1. 项目概述：为什么我们需要“跨进程的锁”和“带容量的门”？

你有没有遇到过这种场景：双击桌面图标，程序毫无反应；再点一次，还是没动静；等三秒后，弹出一个提示框：“程序已在运行，请勿重复启动”。或者，你写了一个日志服务，希望它在整台服务器上只存在一个实例，哪怕有多个用户、多个终端、多个后台脚本同时调用它——它也必须是唯一的。又或者，你开发了一个内部工具，要求同一时间最多只能有3个同事在使用，超过的人得排队等空位。这些需求，单靠 lock 关键字根本解决不了。 lock 是线程级的，它只在当前进程、当前 AppDomain 内有效，就像一把家门钥匙，管得了你家客厅，管不了隔壁老王家的卧室。

而今天要聊的这四个同步构造—— Mutex 、 Semaphore 、 AutoResetEvent 和 ManualResetEvent ——它们才是操作系统层面的“公共资源管理员”。它们不依赖于 .NET 运行时，而是直接调用 Windows 内核对象（Kernel Objects），因此天然具备跨进程、跨用户、甚至跨会话（Session）的能力。你可以把它们理解成四种不同类型的“智能门禁系统”： Mutex 是一把独占式电子锁，只认一个主人； Semaphore 是一个带计数器的闸机，能精确控制并发人数； AutoResetEvent 是一个单次通行的旋转门，插一次卡放一个人； ManualResetEvent 则是一扇可以手动开关的推拉门，开一次，所有排队的人都能涌进去。它们的共同点是：都通过内核对象实现，性能开销比纯托管的 lock 高得多，但换来的是真正的系统级协调能力。如果你的项目里出现了“防止重复启动”、“限制并发访问外部资源（如打印机、数据库连接池、硬件设备）”、“实现跨进程信号通知”这类需求，那你就不是在写代码，而是在设计一套微型的分布式协作协议——而这四个构造，就是你手里的第一套标准工具包。

2. 核心同步构造原理与选型逻辑

2.1 Mutex：系统级的“唯一性契约”

Mutex 的全称是 Mutual Exclusion（互斥体），它的核心语义非常纯粹： 在任意时刻，整个操作系统中，只能有一个线程（无论来自哪个进程）持有它 。这决定了它的两个不可替代的用途：一是进程单例（Single Instance），二是跨进程临界区保护。它的底层实现依赖于 Windows 的内核对象 CreateMutex ，这个对象在创建时会被赋予一个全局唯一的名称（如 "LoveJenny OneAtATimeDemo" ），操作系统内核会维护一个全局的命名对象表，所有进程都可以通过这个名字去查找并尝试获取它。

为什么说它比 lock 慢50倍？我们来拆解一次 WaitOne 调用的完整路径：首先，.NET 的 Mutex.WaitOne() 会触发一次从用户态到内核态的上下文切换（Context Switch），这是最昂贵的操作；接着，内核需要在全局对象表中查找该 Mutex 的句柄，并检查其当前状态（是否已被占用）；如果被占用，当前线程会被挂起，放入该 Mutex 的等待队列中，并触发一次调度器重调度；当持有者调用 ReleaseMutex 时，内核需要唤醒等待队列中的第一个线程，再次触发上下文切换。这一进一出，至少涉及两次完整的 CPU 上下文切换、一次内核对象查找、一次调度决策，耗时自然在毫秒级。而 lock 完全在用户态完成，它只是对一个内存地址执行原子性的 CompareExchange 操作，失败则自旋或短暂休眠，全程不涉及内核，所以快如闪电。

提示： Mutex 的名称 "LoveJenny OneAtATimeDemo" 不是随便起的。它必须是一个合法的全局对象名，不能包含反斜杠 \ （因为 \ 在 Windows 对象命名空间中是分隔符，如 \BaseNamedObjects\MyMutex ），最好避免空格和特殊字符，以确保在不同语言环境下的兼容性。我曾经在一个中文系统里用 "我的互斥体" 命名，结果在英文版 Windows 上完全找不到，调试了整整半天才定位到问题。

2.2 Semaphore：带容量的“并发流量控制器”

Semaphore （信号量）的设计哲学与 Mutex 截然不同。它不追求“唯一”，而是追求“可控”。你可以把它想象成一个共享会议室的预约系统：会议室总共只有3个座位，那么最多允许3个人同时进入。第4个人来了，发现没座，就只能在门口等着；第1个人离开后，第4个人才能进去。 SemaphoreSlim 是 .NET Framework 4.0 引入的轻量级版本，它在大多数情况下（无跨进程需求、无超时等待）会优先在用户态完成操作，避免了昂贵的内核切换，因此性能远超传统的 Semaphore 类。它的构造函数 new SemaphoreSlim(3) 中的 3 ，就是这个“最大并发数”，也就是信号量的初始计数（Initial Count）。

这里有个关键细节常被忽略： Semaphore 的计数是“可增可减”的。每次调用 Wait() ，计数减1；每次调用 Release() ，计数加1。当计数为0时，后续的 Wait() 就会阻塞。这意味着，它不仅可以用来限制“进入”，还可以用来协调“完成”。比如，在一个并行任务中，你启动了10个子线程去处理数据，主线程想等这10个子线程全部完成后再继续。你就可以创建一个初始计数为0的 SemaphoreSlim ，每个子线程完成时调用一次 Release() ，主线程则调用 Wait(10) 来等待10次释放。这是一种非常优雅的“反向信号量”用法。

注意： SemaphoreSlim 的 Wait() 方法是可取消的，它接受一个 CancellationToken 参数。这在长时间运行的服务中至关重要。想象一下，你的服务正在等待一个外部 API 返回，而这个 API 因为网络问题卡住了。如果没有取消机制，你的线程就会永远挂在那里，成为资源黑洞。而有了 CancellationToken ，你可以在超时后主动取消等待，让线程得以回收。

2.3 AutoResetEvent：单次触发的“旋转门”

AutoResetEvent 的名字已经揭示了它的全部行为：“Auto”代表自动，“Reset”代表重置，“Event”代表事件。它本质上是一个二元状态开关： true （已触发/已设置）或 false （未触发/未设置）。它的精妙之处在于“自动重置”这个特性。当你调用 Set() 时，它会将状态设为 true ，并唤醒一个正在 WaitOne() 的线程（如果有）；一旦那个被唤醒的线程开始执行， AutoResetEvent 的状态会 自动 变回 false 。这就像是一个旋转门：你刷一次卡（ Set ），门转一圈，只放行一个人（唤醒一个线程），然后门自动回到关闭状态（ Reset ），等待下一次刷卡。

这个“自动”特性带来了极强的确定性。它保证了每一次 Set() 调用，最多只会唤醒一个等待者。这使得它成为实现“一对一”通知场景的黄金标准，比如经典的生产者-消费者模型。在 ProducerConsumerQueue 示例中， _wh.Set() 就像一个“有活干了”的铃声，只响一次，只叫醒一个正在打盹的工人（消费者线程）。工人醒来后，立刻去取任务，取完后如果队列空了，它又会再次 WaitOne() ，重新进入睡眠。整个过程没有竞态条件，逻辑清晰得像教科书。

实操心得： AutoResetEvent 的初始状态参数 false 或 true ，常常让人困惑。记住一个口诀：“ false 是默认关着的门， true 是刚刷过卡的门”。 new AutoResetEvent(false) 表示门一开始是关着的，谁来 WaitOne() 都得等； new AutoResetEvent(true) 表示门刚刚被刷过卡，处于“刚打开”的瞬间，此时第一个 WaitOne() 会立刻通过，之后门自动关上，第二个 WaitOne() 又得等。这个“初始开门”的状态，只对第一个等待者有效，之后的行为完全由 Set() 控制。

2.4 ManualResetEvent：可手动开关的“推拉门”

如果说 AutoResetEvent 是一个单次通行的旋转门，那么 ManualResetEvent 就是一扇可以手动控制开关的推拉门。它的核心区别在于“手动重置”（Manual Reset）。当你调用 Set() 时，它会将状态设为 true ，并唤醒 所有 正在 WaitOne() 的线程；但它不会自动关上，门会一直开着，直到你显式地调用 Reset() 。这就意味着，一个 Set() 调用，可以“广播”给所有等待者，实现一对多的通知。

这种“广播”能力让它非常适合用于“初始化完成”或“服务启动就绪”这类场景。例如，一个复杂的后台服务，启动时需要加载配置、连接数据库、初始化缓存等多个步骤。主线程可以创建一个 ManualResetEvent ，在所有初始化工作完成后调用 Set() ；而其他所有依赖该服务的子线程，都在启动时调用 WaitOne() ，一旦收到“就绪”信号，就一起开始工作。这样，你就不需要为每个子线程都单独发一个信号，一个 Set() 就搞定了。

ManualResetEventSlim 是它的优化版本，它在首次 WaitOne() 时，会先尝试在用户态自旋等待一小段时间（默认10微秒），如果在这段时间内 Set() 被调用，就无需进入内核态，从而极大提升了短时等待的性能。对于那些预期等待时间很短的场景（比如等待一个快速完成的初始化）， ManualResetEventSlim 是绝对的首选。

3. 实操详解：从代码到生产环境的完整落地

3.1 Mutex 实战：构建坚不可摧的单实例应用

让我们把开头的 MainThread 示例，扩展成一个真正能在生产环境中使用的单实例守护者。原始代码的问题在于：它只在 Main 方法里做了一次检测，如果程序启动后，用户又双击了一次图标，它并不会阻止。我们需要一个更健壮的方案。

public static class SingleInstanceGuard
{
    private static readonly string _mutexName = "Global\\MyApp_SingleInstance_" + 
        Environment.GetEnvironmentVariable("COMPUTERNAME") ?? "Unknown";
    
    private static Mutex _mutex;
    private static bool _isFirstInstance;

    /// <summary>
    /// 尝试获取单实例锁
    /// </summary>
    /// <param name="timeoutMs">超时时间，单位毫秒。0表示不等待，-1表示无限等待</param>
    /// <returns>是否成功获取锁（即是否为首个实例）</returns>
    public static bool TryAcquire(int timeoutMs = 3000)
    {
        try
        {
            // 创建一个全局命名的 Mutex，initiallyOwned 设为 false，
            // 表示我们不希望在创建时就自动获得所有权
            _mutex = new Mutex(false, _mutexName);
            
            // 尝试获取锁，注意：这里用的是 WaitOne，不是直接构造时获取
            _isFirstInstance = _mutex.WaitOne(timeoutMs);
            return _isFirstInstance;
        }
        catch (UnauthorizedAccessException)
        {
            // 在某些受限环境中（如沙盒、容器），可能没有权限创建全局 Mutex
            // 此时降级为进程内单例
            _isFirstInstance = true;
            return true;
        }
        catch (Exception ex) when (ex is IOException || ex is System.Security.SecurityException)
        {
            // 其他异常，如磁盘满、权限不足等，记录日志并降级
            Console.WriteLine($"Mutex 创建失败: {ex.Message}");
            _isFirstInstance = true;
            return true;
        }
    }

    /// <summary>
    /// 释放单实例锁
    /// </summary>
    public static void Release()
    {
        _mutex?.ReleaseMutex();
        _mutex?.Dispose();
        _mutex = null;
    }

    /// <summary>
    /// 获取当前实例是否为首个实例
    /// </summary>
    public static bool IsFirstInstance => _isFirstInstance;
}

这段代码的关键改进点：

1. 全局命名空间 ：使用 "Global\\" 前缀，确保 Mutex 在整个会话（Session）中可见。如果不加前缀，它默认是会话本地的（ "Local\\" ），在 Windows Terminal 或远程桌面中，不同会话的程序会认为自己是“第一个”，导致单实例失效。
2. 异常处理与降级策略 ：生产环境千变万化。在 Docker 容器、某些企业安全策略下，创建全局 Mutex 可能被禁止。我们的代码捕获了 UnauthorizedAccessException ，并优雅地降级为进程内单例，保证程序至少能跑起来，而不是直接崩溃。
3. 超时控制 ： TryAcquire 方法支持自定义超时，避免在极端情况下（如系统资源严重不足）无限期等待。

在 Program.cs 中的使用方式如下：

static void Main(string[] args)
{
    // 尝试获取单实例锁
    if (!SingleInstanceGuard.TryAcquire())
    {
        // 不是第一个实例，向第一个实例发送激活消息（可选）
        ActivateFirstInstance();
        return;
    }

    try
    {
        // 启动主程序
        RunProgram();
    }
    finally
    {
        // 确保锁被释放
        SingleInstanceGuard.Release();
    }
}

private static void ActivateFirstInstance()
{
    // 这里可以实现向已有窗口发送 WM_ACTIVATE 消息，
    // 让它从最小化状态恢复并获得焦点
    // 具体实现需要 P/Invoke 调用 user32.dll
    Console.WriteLine("另一个实例已在运行，正在尝试激活...");
}

3.2 Semaphore 实战：精准控制外部资源的并发访问

假设你正在开发一个公司内部的“打印服务代理”。它负责接收来自各个部门的打印请求，然后将它们分发给一台物理打印机。但这台打印机非常老旧，同时处理超过2个作业就会卡死。你不能让50个部门的请求一股脑涌过去，必须进行严格的流量整形。

public class PrintServiceProxy : IDisposable
{
    // 限制并发打印作业数为2
    private readonly SemaphoreSlim _printSemaphore = new SemaphoreSlim(2, 2);
    private readonly ConcurrentQueue<PrintJob> _jobQueue = new ConcurrentQueue<PrintJob>();
    private readonly Thread _workerThread;
    private volatile bool _isRunning = true;

    public PrintServiceProxy()
    {
        _workerThread = new Thread(WorkerLoop) { IsBackground = true, Name = "PrintWorker" };
        _workerThread.Start();
    }

    public void EnqueuePrintJob(PrintJob job)
    {
        _jobQueue.Enqueue(job);
        // 有新任务，尝试唤醒工作线程
        _printSemaphore.Release();
    }

    private void WorkerLoop()
    {
        while (_isRunning)
        {
            // 等待一个“许可”，或者等待被中断
            if (!_printSemaphore.Wait(1000)) // 等待1秒，超时则检查是否退出
            {
                if (!_isRunning) break;
                continue;
            }

            // 成功获取许可，现在可以尝试取一个任务
            if (_jobQueue.TryDequeue(out var job))
            {
                try
                {
                    // 执行真实的打印逻辑
                    ExecutePhysicalPrint(job);
                }
                catch (Exception ex)
                {
                    // 记录错误，但不要让工作线程退出
                    Console.WriteLine($"打印作业失败: {job.Id}, 错误: {ex.Message}");
                }
                finally
                {
                    // 无论成功失败，都要归还许可，让下一个任务进来
                    _printSemaphore.Release();
                }
            }
            else
            {
                // 队列为空，说明是虚假唤醒，归还许可
                _printSemaphore.Release();
            }
        }
    }

    private void ExecutePhysicalPrint(PrintJob job)
    {
        Console.WriteLine($"[{DateTime.Now:HH:mm:ss}] 开始打印作业: {job.Id}");
        // 模拟耗时的打印操作
        Thread.Sleep(3000);
        Console.WriteLine($"[{DateTime.Now:HH:mm:ss}] 打印作业完成: {job.Id}");
    }

    public void Dispose()
    {
        _isRunning = false;
        _workerThread.Join(5000); // 等待最多5秒
        _printSemaphore?.Dispose();
    }
}

public class PrintJob
{
    public string Id { get; set; }
    public string DocumentPath { get; set; }
    public int Copies { get; set; }
}

这个实现的精妙之处在于：

• 双重保障的许可管理 ： _printSemaphore.Release() 在 EnqueuePrintJob 中调用一次，是为了“通知”工作线程有新任务；而在 WorkerLoop 中，无论任务执行成功与否，都会在 finally 块里再 Release() 一次。这确保了许可的总数永远不会丢失，即使某个任务抛出了未捕获的异常。
• 超时等待与虚假唤醒 ： _printSemaphore.Wait(1000) 的超时机制，让工作线程不会被永久挂起。它每秒检查一次队列，如果队列为空，就认为是“虚假唤醒”，然后继续下一轮循环。这比一个死等的 Wait() 更加健壮。
• 后台线程 ： _workerThread.IsBackground = true ，确保当主程序退出时，这个工作线程会自动结束，不会阻止进程退出。

3.3 AutoResetEvent 实战：重构生产者-消费者队列

原始的 ProducerConsumerQueue 示例虽然功能正确，但在生产环境中存在几个隐患： while(true) 是一个典型的“忙等”陷阱，如果 Set() 和 WaitOne() 的时机配合不好，可能会导致线程在 WaitOne() 前就进入了 while 循环，然后永远卡住；另外， _wh.Close() 在 Dispose 中调用，但如果 Work 线程还在运行， Close 会抛出异常。

我们来做一个更鲁棒的版本：

public class RobustProducerConsumerQueue<T> : IDisposable
{
    private readonly Queue<T> _tasks = new Queue<T>();
    private readonly object _locker = new object();
    private readonly AutoResetEvent _taskAvailable = new AutoResetEvent(false);
    private readonly Thread _workerThread;
    private volatile bool _isDisposed = false;
    private volatile bool _isStopping = false;

    public RobustProducerConsumerQueue()
    {
        _workerThread = new Thread(WorkerLoop) { IsBackground = true };
        _workerThread.Start();
    }

    public void EnqueueTask(T task)
    {
        if (_isDisposed) throw new ObjectDisposedException(nameof(RobustProducerConsumerQueue<T>));
        
        lock (_locker)
        {
            _tasks.Enqueue(task);
        }
        // 通知工作线程：有新任务了！
        _taskAvailable.Set();
    }

    public void Dispose()
    {
        if (_isDisposed) return;
        _isDisposed = true;
        _isStopping = true;
        // 发送一个“停止”信号
        _taskAvailable.Set();
        _workerThread.Join(5000); // 等待最多5秒
        _taskAvailable?.Dispose();
    }

    private void WorkerLoop()
    {
        while (!_isStopping)
        {
            T task = default;
            bool hasTask = false;

            // 先尝试在不加锁的情况下快速检查
            if (_tasks.Count > 0)
            {
                lock (_locker)
                {
                    if (_tasks.Count > 0)
                    {
                        task = _tasks.Dequeue();
                        hasTask = true;
                    }
                }
            }

            if (hasTask)
            {
                // 处理任务
                ProcessTask(task);
            }
            else
            {
                // 没有任务，等待信号
                // 使用带超时的 WaitOne，避免永久挂起
                if (!_taskAvailable.WaitOne(1000))
                {
                    // 超时了，可能是被中断，或者 _isStopping 已被设置
                    if (_isStopping) break;
                    continue;
                }
                // 如果 WaitOne 返回 true，说明收到了 Set 信号，重新循环检查队列
            }
        }
    }

    private void ProcessTask(T task)
    {
        try
        {
            // 这里是你的业务逻辑
            if (task is string s && s == "null")
            {
                // 特殊的停止信号
                _isStopping = true;
                return;
            }
            Console.WriteLine($"[{DateTime.Now:HH:mm:ss}] 正在处理: {task}");
            Thread.Sleep(1000);
        }
        catch (Exception ex)
        {
            Console.WriteLine($"处理任务时出错: {ex.Message}");
        }
    }
}

这个版本的核心改进：

• 无锁快速路径 ：在 WorkerLoop 中，我们首先不加锁地检查 _tasks.Count 。如果队列非空，再进入锁块进行实际的 Dequeue 。这大大减少了锁的竞争，提升了高并发下的吞吐量。
• 安全的停止流程 ： Dispose 方法中，我们先设置 _isStopping = true ，然后调用 _taskAvailable.Set() 来唤醒可能正在 WaitOne() 的工作线程。工作线程在 WaitOne 超时后，会检查 _isStopping 并优雅退出。
• 超时等待 ： _taskAvailable.WaitOne(1000) 的超时机制，是防止工作线程被永久挂起的最后一道保险。

3.4 ManualResetEvent 实战：实现服务的优雅启停

在微服务架构中，一个服务的启动和停止必须是可预测、可控制的。 ManualResetEvent 是实现这种“门控”逻辑的理想工具。

public class GracefulServiceHost : IDisposable
{
    private readonly ManualResetEventSlim _startupComplete = new ManualResetEventSlim(false);
    private readonly ManualResetEventSlim _shutdownInitiated = new ManualResetEventSlim(false);
    private readonly List<Task> _backgroundTasks = new List<Task>();

    public async Task StartAsync()
    {
        Console.WriteLine("服务启动中...");

        // 1. 加载配置
        await LoadConfigurationAsync();

        // 2. 初始化数据库连接池
        await InitializeDatabaseAsync();

        // 3. 启动后台健康检查任务
        _backgroundTasks.Add(StartHealthCheckTask());

        // 4. 所有准备工作完成，发出“启动完成”信号
        _startupComplete.Set();
        Console.WriteLine("服务启动完成，已就绪。");
    }

    public async Task StopAsync()
    {
        Console.WriteLine("服务正在优雅关闭...");

        // 1. 发出“关闭开始”信号，通知所有组件准备收尾
        _shutdownInitiated.Set();

        // 2. 等待所有后台任务完成，最多等待30秒
        await Task.WhenAll(_backgroundTasks).WaitAsync(TimeSpan.FromSeconds(30));

        // 3. 清理资源
        await CleanupResourcesAsync();

        Console.WriteLine("服务已完全关闭。");
    }

    /// <summary>
    /// 等待服务启动完成
    /// </summary>
    public void WaitForStartup() => _startupComplete.Wait();

    /// <summary>
    /// 检查服务是否已启动
    /// </summary>
    public bool IsStarted => _startupComplete.IsSet;

    /// <summary>
    /// 检查服务是否已开始关闭
    /// </summary>
    public bool IsShuttingDown => _shutdownInitiated.IsSet;

    private async Task LoadConfigurationAsync()
    {
        await Task.Delay(1000); // 模拟加载
        Console.WriteLine("配置加载完成。");
    }

    private async Task InitializeDatabaseAsync()
    {
        await Task.Delay(2000); // 模拟初始化
        Console.WriteLine("数据库连接池初始化完成。");
    }

    private async Task StartHealthCheckTask()
    {
        while (!IsShuttingDown)
        {
            Console.WriteLine($"[{DateTime.Now:HH:mm:ss}] 执行健康检查...");
            await Task.Delay(5000);
        }
    }

    private async Task CleanupResourcesAsync()
    {
        await Task.Delay(1000);
        Console.WriteLine("资源清理完成。");
    }

    public void Dispose()
    {
        _startupComplete?.Dispose();
        _shutdownInitiated?.Dispose();
    }
}

在这个 GracefulServiceHost 中， _startupComplete 和 _shutdownInitiated 就像两扇大门：

• _startupComplete 是一扇“启动完成门”。所有依赖此服务的组件（比如一个 Web API Controller），在处理请求前，都会先调用 WaitForStartup() 。这确保了任何请求都不会在服务真正准备好之前被处理，避免了 NullReferenceException 等因资源未初始化导致的错误。
• _shutdownInitiated 是一扇“关闭开始门”。当 StopAsync 被调用，它被 Set() ，所有正在运行的后台任务（如健康检查）都能通过 IsShuttingDown 属性感知到关闭信号，并主动退出循环，开始自己的清理工作。

这种基于事件的启停模式，让服务的生命周期变得完全透明和可控，是构建高可用、可运维系统的基石。

4. 常见问题与排查技巧实录

4.1 Mutex 相关问题速查表

4.2 Semaphore 相关问题速查表

4.3 AutoResetEvent / ManualResetEvent 相关问题速查表

4.4 综合避坑指南：资深开发者踩过的坑

• 坑一：在 finally 块里 Dispose() 一个可能为 null 的对象
  这是 C# 中一个非常隐蔽的陷阱。 Mutex.Dispose() 和 EventWaitHandle.Dispose() 方法本身是幂等的，但如果你的代码是 _mutex?.Dispose() ，看起来很安全。然而，如果 _mutex 是一个 null ， ?. 操作符会直接跳过，什么也不做。这没问题。但如果你写成了 _mutex.Dispose() ，而 _mutex 是 null ，就会抛出 NullReferenceException 。 我的经验是：永远使用 ?.Dispose() ，并且在 Dispose 方法的开头，添加一个 if (disposed) return; disposed = true; 的守卫模式，确保 Dispose 可以被安全地多次调用。

• 坑二： WaitOne() 的超时时间单位是毫秒，但 TimeSpan.FromSeconds(3) 是秒
  这个错误太常见了。 WaitOne(int millisecondsTimeout) 的参数是毫秒，而 TimeSpan.FromSeconds(3) 是3秒。如果你写了 mutex.WaitOne(TimeSpan.FromSeconds(3)) ，它等效于 mutex.WaitOne(3000) ，这是正确的。但如果你写了 mutex.WaitOne(3) ，那它就只等3毫秒，几乎等于没等。 我的习惯是：永远显式地写出单位，比如 WaitOne(3000) 或 WaitOne(TimeSpan.FromMilliseconds(3000)) ，绝不依赖 TimeSpan 的隐式转换，以防混淆。

• 坑三：在 async/await 方法中错误地使用同步等待原语
  WaitOne() 、 Wait() 等方法都是同步阻塞的。如果你在一个 async 方法中直接调用它们，会阻塞当前线程，破坏 async 的初衷。 正确的做法是： .NET Core 6+ 提供了 WaitAsync(CancellationToken) 的异步版本。对于 SemaphoreSlim ，它有 WaitAsync() ；对于 ManualResetEventSlim ，它也有 WaitAsync() 。而对于 Mutex 和传统的 EventWaitHandle ，它们没有内置的异步方法，此时你应该考虑重构逻辑，或者使用 Task.Run(() => mutex.WaitOne()) 将其包装成一个 Task ，但这会带来额外的线程开销，应作为最后的选择。

• 坑四：过度设计，用错了工具
  最后，也是最重要的一点。我见过太多项目，为了追求“技术先进”，在完全不需要跨进程协调的地方，强行使用 Mutex 。结果是，性能下降了50倍，代码复杂度翻倍，却只换来一个毫无意义的“全局唯一”。 请永远牢记： lock 是你的第一选择， SemaphoreSlim 是你的第二选择， AutoResetEvent 是你的第三选择。只有当 lock 解决不了问题时，才去考虑 SemaphoreSlim ；只有当 SemaphoreSlim 无法表达你的“通知”语义时，才去考虑 AutoResetEvent ；只有当 AutoResetEvent 无法满足你的“广播”需求时，才去考虑 ManualResetEvent ；而 Mutex ，则是你最后的、也是最重的武器，只在“系统级单例”或“跨进程临界区”这种刚需场景下才亮出来。 工具的价值不在于它有多酷，而在于它是否能用最简单的方式，解决最真实的问题。