string不适合作为锁对象，因其被字符串驻留机制共享，导致意外死锁、缺乏唯一性与可控性，且null值会抛NullReferenceException；应使用私有readonly object字段。
lock 一个 string 可能导致意外的死锁或阻塞
因为 string 是可被字符串驻留（string interning）的类型，相同字面值的 string 在运行时可能指向同一个对象。你本想保护某段逻辑只被当前业务线程串行执行，结果却和完全无关的模块（比如日志组件、配置解析、第三方库）共用了同一把锁。
- 例如
lock ("MyResource")和另一处lock ("MyResource")（哪怕在不同类、不同程序集）会实际锁住同一个对象 - .NET 默认对编译期确定的字符串字面量自动驻留；
string.Intern()显式驻留后也一样 - 一旦某个地方持有该字符串锁时间过长（比如锁内调用外部 API），所有其他碰巧用同名字符串加锁的地方都会卡住
为什么 string 不适合当锁对象
锁对象的核心要求是：唯一性、可控性、生命周期明确。string 违反全部三点：
- 唯一性：无法保证——
"key"和new string('k',1) + "ey"经驻留后可能等价 - 可控性：你不能阻止别人也用相同内容的字符串去
lock - 生命周期：驻留字符串存活至 AppDomain 卸载，锁对象长期滞留，GC 无法回收
- 更隐蔽的问题：
lock (someString)中若someString为null，会直接抛出NullReferenceException，而非SynchronizationLockException
安全替代方案：用专用的 object 实例
最简单可靠的方式是声明一个私有的、只用于锁定的 object 字段：
private readonly object _lockObject = new object();
public void DoWork()
{
lock (_lockObject)
{
// 安全的临界区
}
}
- 确保字段是
readonly，避免被意外赋值替换 - 不要用
this、typeof(MyClass)或公共属性做锁对象——它们暴露给外部，破坏封装 - 若需按 key 区分锁（如 per-user 锁），改用
ConcurrentDictionary+GetOrAdd，但要注意键的唯一性和清理问题
真要锁字符串？至少得绕过驻留
极少数场景下（比如必须基于动态生成的字符串做同步，且已知不会重复），可强制避免驻留：
- 用
string.Create()或非字面量拼接（如StringBuilder.ToString()）生成的字符串默认不驻留 - 但仍建议包装一层：构造一个包含该字符串的私有
class LockKey { public string Value; }，再lock (new LockKey { Value = s })——这样至少避免跨上下文误共享 - 注意：这种写法仍无法防止逻辑错误（比如两次传入相同字符串却期望不同锁），只是降低了“撞锁”概率
string 当锁，等于把线程安全交给了字符串驻留机制和运气。 
