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<string object></string>+
GetOrAdd，但要注意键的唯一性和清理问题
真要锁字符串？至少得绕过驻留
极少数场景下（比如必须基于动态生成的字符串做同步，且已知不会重复），可强制避免驻留：
用string.Create()或非字面量拼接（如
StringBuilder.ToString()）生成的字符串默认不驻留 但仍建议包装一层：构造一个包含该字符串的私有
class LockKey { public string Value; }，再 lock (new LockKey { Value = s }) ——这样至少避免跨上下文误共享
注意：这种写法仍无法防止逻辑错误（比如两次传入相同字符串却期望不同锁），只是降低了“撞锁”概率
锁对象不是语法糖，它是并发意图的显式契约。用 string当锁，等于把线程安全交给了字符串驻留机制和运气。
