C# ViewModel中使用lock处理多线程竞态的正确性及用法咨询

你当前的lock用法存在根本性错误，不仅无法解决竞态问题，还会埋下极难调试的故障隐患，对lock机制的理解存在几个关键偏差。

第一个核心错误：锁对象选择完全错误 #

你当前代码中直接锁_theField、_fullName这类字符串字段，是完全无效的同步写法：

• string是不可变类型，当你在setter中执行_theField = value时，字段指向的对象已经变成了新的字符串实例，后续线程进入getter/setter时锁的是新对象，和之前线程持有的锁根本不是同一个同步根，完全起不到互斥作用。
• 字符串存在CLR内部的留用机制，相同字面量的字符串可能在整个进程内共享实例，可能出现和其他完全不相关的代码意外共用同一个锁的问题，导致莫名的阻塞甚至死锁。
• 通用规则：永远不要锁会被修改的字段、字符串、this、公开的Type实例，锁对象必须是私有、只读、永不修改的专用同步实例。

第二个认知偏差：多字段同步的锁使用方式错误 #

你给出的两种派生字段的写法全错，问题包括：

1. 依然存在锁字符串字段的根本性问题，同步完全失效。
2. 第二种写法嵌套锁两个不同对象，只要后续代码中出现反向加锁（比如操作FirstName时先锁_firstName再锁_fullName），100%会触发死锁，这类偶现死锁在生产环境极难定位复现。

正确的做法是：所有存在逻辑关联、需要保证原子读写的共享状态，必须共用同一个专用锁对象，根本不需要嵌套加锁。

第三个需要注意的点：UI线程模型问题 #

如果你的ViewModel是给WPF/WinForm等UI框架做绑定用，默认情况下属性本身就应该只在UI线程访问，后台线程执行完耗时任务后，应该通过框架提供的调度器把更新逻辑切回UI线程执行，这是比加锁更稳妥的方案，从根源上避免跨线程竞态。lock是兜底手段，不是这类场景的优先解决方案。

另外你提到的「不在lock块内写await」这个认知是正确的，C#编译器直接禁止这种写法就是因为lock是线程仿射的，await后的线程切换会导致锁无法被正确释放。但要注意：await执行完成后，之前持有的锁已经释放，后续代码如果要访问共享状态，必须重新获取锁，不能默认还在锁的保护范围内。

正确代码示例 #

单字段场景的正确写法 #

// 专用只读锁对象，自始至终不会被修改，保证所有线程锁的是同一个实例
private readonly object _theFieldLock = new object();
private string _theField;

public string TheField {
    get {
        lock(_theFieldLock) {
            return _theField;
        }
    }
    set {
        lock(_theFieldLock) {
            _theField = value;
        }
    }
}

关联派生字段的正确写法 #

所有相关字段共用同一个锁对象，保证读写的原子性，不需要嵌套加锁：

private readonly object _nameLock = new object();
private string _fullName;
private string _firstName;

public string FullName {
    get {
        lock(_nameLock) {
            return _fullName;
        }
    }
    set {
        lock(_nameLock) {
            _fullName = value;
            // 锁内直接完成关联字段的赋值，保证两个字段状态永远一致
            _firstName = _fullName.Split(" ")[0];
        }
    }
}

public string FirstName {
    get {
        lock(_nameLock) {
            return _firstName;
        }
    }
    // 如果存在FirstName的setter，同样必须锁_nameLock，绝对不能使用其他锁对象
}

额外建议 #

• 锁的持有时间要尽可能短，不要在锁内执行耗时操作，避免阻塞其他线程。
• 如果确定所有属性访问都能调度到UI线程执行，可以完全去掉锁，减少不必要的性能开销和死锁风险。
• 不要为每个字段单独创建锁，只有完全无关、不需要保证原子操作的状态才可以使用独立的锁。

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