.NET为何为SemaphoreSlim同时提供Wait()与WaitAsync()方法？

这个问题问到点子上了——混合使用SemaphoreSlim.Wait()和WaitAsync()确实是个隐蔽的大坑，那种线程上下文嵌套导致的死锁场景，哪怕是有经验的开发者都很容易踩中，完全不直观。我来拆解一下这个问题的核心：

一、SemaphoreSlim提供同步Wait()的初衷 #

SemaphoreSlim的设计定位是进程内轻量级同步原语，和传统的Semaphore（系统级、支持跨进程）最大的区别就是开销极低——它的大部分操作在用户态就能完成，只有当资源竞争激烈时才会触发内核态调用。

而传统Semaphore的Wait()因为是系统级API调用，性能开销要大得多。所以对于只需要在单个进程内做同步的纯同步代码场景，用SemaphoreSlim.Wait()比Semaphore.Wait()更高效。比如一个同步的批量数据处理方法需要限制并发数，用轻量级的SemaphoreSlim能显著减少性能损耗，这就是同步Wait()的合理使用场景。

二、混合使用Wait()和WaitAsync()的真实风险（也就是你提到的死锁） #

你描述的死锁场景完全是真实存在的，而且隐蔽到让人防不胜防：

1. 异步代码调用WaitAsync()获取信号量，await后TaskScheduler把后续逻辑调度到了其他线程；
2. 此时另一个同步任务被调度到同一个原生线程上执行，调用Wait()尝试获取同一个信号量；
3. 因为信号量已经被持有，同步Wait()会直接阻塞这个线程，但这个线程刚好是之前持有信号量的异步上下文绑定的线程——结果就是死锁：异步代码等着线程释放，同步代码等着信号量释放，双方互相卡住，谁也动不了。

这种场景之所以容易踩坑，就是因为TaskScheduler的调度逻辑对开发者是完全透明的，没人会想到同步代码会刚好被调度到持有信号量的那个线程上。

三、为什么微软要保留这种“危险”的灵活性？ #

微软的设计思路一直是给开发者足够的灵活性，同时把风险明确告知开发者。SemaphoreSlim的同步Wait()确实带来了实用的灵活性：

• 比如在重构同步代码到异步的过渡阶段，开发者可以先在同步代码里用SemaphoreSlim.Wait()，然后逐步把同步方法改成异步，用WaitAsync()替换，不用中途切换同步原语；
• 或者某些极端场景下，同步和异步的代码路径完全隔离（比如同步方法和异步方法永远不会交叉调用，也不会共享线程上下文），这时候混合使用是安全的。

但问题是，这种“安全的混合场景”门槛极高，很容易因为后续代码的微小修改就打破平衡，触发死锁。

四、正确的使用姿势 #

回到你的核心疑问：永远不要在同一个SemaphoreSlim实例上混合使用Wait()和WaitAsync()，这是避免死锁的黄金法则：

• 如果你的类是纯同步的，放心用SemaphoreSlim.Wait()（比传统Semaphore高效太多）；
• 如果你的类是纯异步的，全程只用SemaphoreSlim.WaitAsync()；
• 如果必须在同步和异步之间共享资源，要么把同步方法改成异步（比如把你的SomeProperty改成ValueTask<bool> GetSomePropertyAsync()），要么直接用传统的Semaphore（虽然开销大，但不会有这种线程上下文导致的死锁问题）。

比如你的伪代码可以改成纯异步的安全版本：

public class SomeClass 
{ 
    private readonly SemaphoreSlim _semaphore = new(initialCount: 1); 
    private List<object> _someList = new(); 

    public async ValueTask<bool> GetSomePropertyAsync() 
    { 
        await _semaphore.WaitAsync().ConfigureAwait(false); 
        try 
        { 
            return _someList.Any(); 
        } 
        finally 
        { 
            _semaphore.Release(); 
        } 
    } 

    public async Task<bool> AddToListAsync(object item) 
    { 
        await _semaphore.WaitAsync().ConfigureAwait(false); 
        try 
        { 
            _someList.Add(item); 
            await Task.Delay(0).ConfigureAwait(false); 
            return true; 
        } 
        finally 
        { 
            _semaphore.Release(); 
        } 
    } 
}

最后总结 #

SemaphoreSlim提供同步Wait()的核心原因是给纯同步场景提供轻量级的同步选项，替代性能开销大的传统Semaphore。但它确实容易让开发者产生“混合使用安全”的错觉，这是灵活性和安全性之间的权衡。关键还是开发者要明确其中的风险，严格避免在同一个实例上混合使用两种等待方法。

内容来源于stack exchange