.NET 9中System.Threading.Lock的适用场景及异步安全等技术疑问

题外话：await SemaphoreSlim.WaitAsync().ConfigureAwait(false)是否安全？ #

完全安全。ConfigureAwait(false)的作用是避免捕获当前同步上下文，让后续代码可以在任意线程池线程上执行。WaitAsync本身不依赖调用时的上下文，所以加上这个配置不会引发问题，反而能在非UI线程场景下提升性能，减少不必要的上下文切换开销。

System.Threading.Lock的核心定位与特性 #

先明确：System.Threading.Lock不是异步安全的，它是对传统lock(object)语法的增强，依然是线程绑定的同步锁——持有锁的代码中绝对不能使用await，否则会导致锁被错误地释放到其他线程，引发线程安全问题。

它相比传统lock的核心优势：

• 原生递归支持：同一线程可多次获取同一Lock，不会触发死锁，和传统lock行为一致但实现更高效
• 非阻塞锁获取：通过TryLock方法可尝试获取锁并指定超时时间，避免线程无限等待
• 类型安全：作为专门的同步原语，避免了传统lock的常见误用（比如用值类型装箱、字符串常量或可修改对象作为锁）
• 性能优化：底层实现比传统lock更高效，尤其是高并发竞争场景下的开销更低

适用场景 #

虽然不支持异步，但它在纯同步场景下的表现远优于传统lock，适用场景包括：

1. 纯同步的临界区操作 #

比如你提到的缓存反射信息、计算集合统计值（总数量、总重量）这类无异步操作的同步代码。这类场景下，Lock比传统lock更安全、性能更优。
优化后的反射缓存示例：

private static Dictionary<string, PropertyInfo> _props = null;
private static readonly System.Threading.Lock _myLock = new System.Threading.Lock();

public Dictionary<string, PropertyInfo> Props
{
    get
    {
        if (_props != null)
            return _props;

        using (_myLock.Enter()) // 自动释放锁，无需手动finally
        {
            if (_props != null)
                return _props;
            _props = GetType().GetProperties().ToDictionary(p => p.Name);
        }
        return _props;
    }
}

2. 高并发的同步资源访问 #

对于需要频繁加锁、释放锁的同步场景（比如内存缓存更新、共享集合修改），Lock的性能表现优于传统lock，底层实现减少了不必要的系统调用开销。

3. 需要非阻塞锁逻辑的场景 #

如果你的代码需要尝试获取锁，超时则执行降级逻辑而非一直等待，Lock的TryLock方法比传统Monitor.TryEnter更简洁易用：

if (_myLock.TryLock(TimeSpan.FromMilliseconds(100)))
{
    try
    {
        // 执行临界区操作
    }
    finally
    {
        _myLock.Exit();
    }
}
else
{
    // 获取锁超时，执行降级逻辑
}

为什么要引入System.Threading.Lock？ #

你觉得它应用场景有限，是因为聚焦于异步场景，但同步代码依然大量存在：

• 很多底层库、工具类仍为纯同步实现，不需要异步操作
• 它解决了传统lock的诸多误用问题，比如避免开发者用错误的对象作为锁
• 提供了更灵活的锁获取方式（非阻塞、超时），而传统lock语法只能通过Monitor类实现这类逻辑，代码繁琐易出错

同步锁的选择建议 #

• 如果代码中存在await操作：必须使用SemaphoreSlim（或其他异步同步原语，比如第三方库的AsyncLock）
• 如果代码是纯同步的：优先选择System.Threading.Lock，它比传统lock更安全高效，也比SemaphoreSlim更轻量（SemaphoreSlim为异步场景设计，同步场景下性能不如Lock）

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