Asp.Net Core中SemaphoreSlim跨单例类多方法使用是否可行？

你在单例构造函数中初始化new SemaphoreSlim(1,1)做类级别互斥的思路是可行的，符合SemaphoreSlim的设计使用规范，但你贴出的方法层实现存在严重隐患，不能直接投入生产使用。

• 信号量永久泄漏：当前写法中_sm.Release()直接写在业务逻辑之后，如果业务执行过程抛出任何异常，Release()就不会被执行，信号量会一直处于被占用状态，后续所有调用该类任意方法的请求都会永久阻塞，直接导致这个单例服务完全不可用。
• 无防护的无限等待：代码中WaitAsync()没有传入超时时间或取消令牌，一旦持有信号量的业务逻辑出现意外阻塞（比如外部依赖调用无超时、数据库死锁、死循环），所有后续请求都会无限期挂起，最终拖垮服务线程池。
• 重入死锁：SemaphoreSlim不会识别当前持有锁的异步执行上下文，如果某方法持有信号量期间调用了类内其他同样需要获取信号量的方法，会直接触发死锁——信号量计数已经被占满，第二次等待永远拿不到释放信号。

核心修复逻辑是用try/finally块保证信号量无论业务执行成功或失败都能被释放，同时增加等待超时避免无限阻塞，参考代码如下：

public class Foo
{
   private readonly SemaphoreSlim _sm;
   // 根据业务容忍度配置最大等待时长，单位毫秒
   private const int MaxWaitMs = 3000;

   public Foo()
   { 
      _sm = new SemaphoreSlim(1, 1);
   }

   public async Task FirstMethod(CancellationToken cancellationToken = default)
   {
      if (!await _sm.WaitAsync(MaxWaitMs, cancellationToken))
      {
          throw new InvalidOperationException("服务处理繁忙，请稍后重试");
      }
      try
      {
          // 此处编写实际业务逻辑
      }
      finally
      {
          _sm.Release();
      }
   }

   public async Task SecondMethod(CancellationToken cancellationToken = default)
   {
      if (!await _sm.WaitAsync(MaxWaitMs, cancellationToken))
      {
          throw new InvalidOperationException("服务处理繁忙，请稍后重试");
      }
      try
      {
          // 此处编写实际业务逻辑
      }
      finally
      {
          _sm.Release();
      }
   }
}

• 缩小锁粒度：类级别的全局互斥会把该服务的并发吞吐量直接降到1，在Web API场景下会严重影响接口性能。优先梳理需要互斥的核心原因：如果只是类内部某一个共享状态（比如缓存字典、文件句柄、串口资源）的读写存在竞态，只需要在访问该共享资源的代码段加锁即可，不需要把整个方法都包裹在锁内。
• 消除重复模板代码：如果类中互斥方法较多，可以用AOP动态代理（比如Castle.Core）、或者封装统一的委托执行方法，把Wait/try/finally的逻辑抽离到公共位置，避免后续新增方法时漏写释放逻辑。
• 避免锁内重入：业务设计上尽量不要出现锁持有期间调用同类其他加锁方法的逻辑，如果确实有重入需求，可以搭配AsyncLocal<T>存储当前持锁的上下文标识，识别到同上下文重入时直接放行，避免死锁。

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