您是否应该在.NET中请求锁定超时？

在发布它!迈克尔·尼加德(Michael Nygard)认为,许多灾难性的系统故障往往是由一连串的事情造成的.例如,两个线程死锁.现在线程池中的线程少了两个,因此其他线程上的负载增加会增加其死锁的可能性.突然,服务器根本没有响应,因为线程池耗尽,导致负载均衡器将流量转移到其他服务器(所有服务器都运行相同的代码),这增加了死锁的可能性.突然整个农场都处于脱机状态.

大多数RDBMS服务器检测到死锁并决定"失败者"(一个事务中止,另一个事务可以继续).相反,在C#中,lock语句将无限期地等待获取锁.

但是,您可以调用Monitor.TryEnter(lockObject,TimeSpan)来请求锁定或超时.如果超时到期并且无法获取锁定,则返回false.有些人在使用语句中将其包装起来以保持良好的语法.

所以我的问题是,你是否总是使用超时获取锁定？除了死锁情况外,超时会产生哪些问题？

我通常会使用超时.这里最大的问题是,如果达到超时,请求操作将被中止.这显然更适合死锁.但是有一个更大的问题:如果操作很关键并且你因为其他东西已经死锁而开始中止,如果你的设计不合理,你可能最终导致你通过这种方法描述的农场减少问题(虽然更软:你的应用程序将不再有效,但你没有失去控制权).

主要的区别在于你实际上有控制权,而如果线程开始死锁,那么在你的代码中没有什么可以在失败开始后修复问题.