2种不同场景下的锁性能

Question

我有一个包含 2 个内联列表的类，其中包含超过 1000 个元素，

public class A
{
    private List<long> aList = new List<long>();
    private List<long> bList = new List<long>();
    void MethodThatUsesAList()
    {
      //Works with aList
    }
    void MethodThatUsesBList()
    {
      //Works with bList
    }
    void MethodThatUsesBoth()
    {
      //Works with both lists
    }
}

现在，我想让这个类线程安全，并且我看到使用锁有 2 种不同的场景，首先

object _synchObject = new object()

在所有方法中创建并锁定这个对象， 或者第二个在使用每个列表时锁定它， 我的第一个问题是，哪种方法是首选？ 如果首选第二种，那么使用这样的锁是否会产生性能问题？

    void MethodThatUsesBoth()
    {
       lock(aList){
           lock(bList){
                 //Works with both lists
           }
       }
    }

Answer 1

这里有两个单独的问题：

• 是否使用一个组合锁或两个单独的锁
• 是否使用单独的对象来锁定列表本身（或它们的 SyncRoot）

这些在某种程度上是可分离的 - 在如果您使用两个单独的锁，则可以创建两个单独的对象来锁定，每个列表一个。

如果您希望 MethodThatUsesAList 和 MethodThatUsesBList 能够同时运行，则需要两个单独的锁。然后，您必须确保任何时候您可能获取两个锁时，都以相同的顺序获取它们。这意味着要对获取锁的任何方法中的所有代码进行推理：例如，您需要确保它不会调用获取另一个锁的另一个方法。

如果您的特定场景不太可能因所有方法被运行任何其中任何一个线程而有效地阻止其他线程而受到太大影响，那么我会使用单锁只是为了简单起见。

无论哪种情况，我个人都会选择其他代码不知道的“私有”锁。我发现以这种方式编写的代码更容易推理。使用列表本身或同步根可能绝对没问题 - 但我只是更喜欢考虑其他任何东西都无法获取的锁。

Answer 2

void MethodThatUsesBoth()
{
   lock(((ICollection)aList).SyncRoot){
       lock(((ICollection)bList).SyncRoot){
             //Works with both lists
       }
   }
}
void MethodThatUsesAList()
{
   lock(((ICollection)aList).SyncRoot){

   }
}
void MethodThatUsesBList()
{
   lock(((ICollection)bList).SyncRoot){

   }
}

在您的其他解决方案中，我认为这不好，因为当您仅在 aList 上工作时，您会阻止对 bList 的访问。这不是一个好的性能解决方案。

Answer 3

一般来说，我认为前者（否则未使用的互斥锁）是首选。这样做没有真正的成本，而且很容易让后者出错，太容易造成僵局。