5

根据语言规范lock(obj) statement;将编译为：

object lockObj = obj; // (the langspec doesn't mention this var, but it wouldn't be safe without it)
Monitor.Enter(lockObj);
try
{
    statement;
}
finally
{
    Monitor.Exit(lockObj);
}

但是，它被编译为：

try
{
    object lockObj = obj;
    bool lockTaken = false;
    Monitor.Enter(lockObj, ref lockTaken);
    statement;
}
finally
{
    if (lockTaken) Monitor.Exit(lockObj);
}

这似乎比必要的复杂得多。所以问题是，这种实施的优势是什么？

4

2 回答 2

5

与往常一样，Eric Lippert 已经回答了这个问题：

编码中的奇妙冒险：锁和异常不能混用

于 2012-06-07T15:46:13.460 回答
2

最近我在“CLR via C#”中读到它实际上可能不是一个优势。原因是该finally块总是释放锁定的资源，即使该try块由于意外错误而退出。这可能会使资源处于未定义状态并且可以访问。程序不会死锁，但错误可能更微妙，因此更难找到。

这当然取决于情况，但我想lock如果您的优先级是防止由于在最坏的情况下意外中断线程而导致死锁，那么当前的实现最有意义。

于 2012-06-30T22:21:33.300 回答