何时适合使用最大计数为1的Semaphore？为何不选用Mutex等同步原语？

好问题！其实用初始计数为1的Semaphore或SemaphoreSlim来实现单线程独占访问是技术上可行的，但确实在多数场景下，lock、Monitor或者（跨进程时的）Mutex是更合适的选择，咱们拆开来说：

核心差异与适用场景 #

• lock/Monitor：这是单进程内线程同步的首选方案。lock本质是Monitor.Enter和Monitor.Exit的语法糖，语法简洁到极致，性能优异，而且所有C#开发者看到lock就知道这是在做单线程独占访问，完全不会有误解。它还能自动处理异常（try/finally的逻辑被封装在语法糖里），几乎不会出现资源泄漏的问题。
• SemaphoreSlim(1,1)：它的设计初衷是控制并发访问的数量（比如允许3个线程同时访问资源池）。用它来做单线程独占，技术上没问题，但会让其他维护代码的开发者困惑——看到SemaphoreSlim第一反应是“这里要限制并发数”，而不是“这里要独占”，可读性大打折扣。不过它有一个独特优势：支持异步等待。如果你的代码是异步方法，lock无法使用（因为lock会阻塞线程，且不能在await前后保持同一个线程上下文），这时候SemaphoreSlim(1,1)就是合理的选择，比如：

  private readonly SemaphoreSlim _asyncLock = new SemaphoreSlim(1, 1);
  
  public async Task ProcessAsync()
  {
      await _asyncLock.WaitAsync();
      try
      {
          // 这里是需要独占访问的异步操作
          await SomeAsyncWork();
      }
      finally
      {
          _asyncLock.Release();
      }
  }
  

• Mutex：它是跨进程的同步原语，能在多个独立进程之间同步线程。但在单进程内使用Mutex完全没必要——它的性能比lock差很多，而且需要手动确保释放（哪怕发生异常），一旦进程崩溃还可能导致Mutex残留，需要手动清理。只有当你需要跨进程同步时，才考虑用它。

总结建议 #

• 如果是同步场景、单进程内，直接用lock，别纠结其他方案，简洁、高效、无歧义。
• 如果是异步场景，SemaphoreSlim(1,1)是合适的替代方案，这也是它唯一适合做“独占”的场景。
• 只有需要跨进程同步时，才考虑Mutex，单进程内尽量避开。

内容的提问来源于stack exchange，提问作者Daniel Neel