托管线程处理的最佳作法

托管线程处理的最佳作法

MSDN

多线程编程须要在编程时倍加注意。对于多数任务，经过将执行请求以线程池线程的方式排队，能够下降复杂性。本主题将探讨更复杂的情形，好比协调多个线程的工做或处理形成阻止的线程。

死锁和争用条件

多线程编程解决了吞吐量和响应性问题，但引入此功能会带来新的问题：死锁和争用条件。

死锁

当两个线程中的每个线程都在试图锁定另一个线程已锁定的资源时，就会发生死锁。其中任何一个线程都不能继续执行。

托管线程处理类的许多方法都提供了超时设定，可帮您检测到死锁。例如，下面的代码试图获取对当前实例的锁定。若是在 300 毫秒内未能锁定，Monitor.TryEnter 将返回 false。

if (Monitor.TryEnter(this, 300)) {
    try {
        // Place code protected by the Monitor here.
    }
    finally {
        Monitor.Exit(this);
    }
}
else {
    // Code to execute if the attempt times out.
}

争用条件

争用条件是当程序的结果取决于两个或更多个线程中的哪个先到达某一特定代码块时出现的一种 Bug。屡次运行程序将产生不一样的结果，并且给定的任何一次运行的结果都不可预知。

争用条件的一个简单例子是递增一个字段。假定某个类有一个私有 static 字段（在 Visual Basic 中为 Shared），每建立该类的一个实例时它都递增一次，使用的代码是 objCt++; (C#) 或 objCt += 1 (Visual Basic)。此操做要求将 objCt 中的值加载到一个寄存器中，使该值递增，而后将其存储到 objCt 中。

在多线程应用程序中，一个已加载并递增该值的线程可能会被另外一个线程抢先，抢先的线程执行所有的三个步骤；当第一个线程继续执行并存储其值时，它改写 objCt，但不考虑该值在它暂停执行期间已更改这一事实。

这种争用条件经过使用 Interlocked 类的方法，如 Interlocked.Increment，便可轻松避免。若要了解在多个线程间同步数据的其余技巧，请参见为多线程处理同步数据。

争用条件也可能会在同步多个线程的活动时发生。编写每一行代码，都必须考虑出现如下特殊状况时会发生什么状况，这里的特殊状况是指：一个线程在执行该行代码（或构成该行的任何机器指令）前，其余线程抢先执行了该代码。

处理器数目

多线程编程技术可以解决单处理器计算机和多处理器计算机的诸多问题，单处理器计算机大多用来运行最终用户软件，多处理器计算机一般用做服务器。

单处理器计算机

多线程编程为计算机用户提供了更好的响应能力，而且使用空闲时间处理后台任务。若是在单处理器计算机上使用多线程编程，那么：

• 在任什么时候刻都只有一个线程在运行。

• 后台线程仅在主用户线程空闲时才执行。连续运行的前台线程将使后台线程得不处处理器时间。

• 对一个线程调用 Thread.Start 方法时，此线程只有等到当前线程结束或被操做系统抢占后才会执行。

• 出现争用条件的缘由一般是，程序员未预见到一个线程可能会在一个难以控制的时刻被抢占这一事实，有时就会出现另外一线程抢先使用代码块这种状况。

多处理器计算机

多线程编程提供了更大的吞吐量。十个处理器能够完成一个处理器的十倍的工做量，不过，只有将任务分开并让十个处理器同时工做才行；线程为划分任务并利用额外的处理能力提供了一种方便的办法。若是在多处理器计算机上使用多线程编程，那么：

• 能够并发执行的线程的数目取决于处理器的数目。

• 后台线程只有在正在执行的前台线程的数目小于处理器的数目时才执行。

• 当您对一个线程调用 Thread.Start 方法时，此线程可能会，也可能不会当即执行，具体取决于处理器数目和当前在等待执行的线程的数目。

• 争用条件不只可能由于线程被意外抢占而发生，还可能由于在不一样的处理器上执行的两个线程在抢用同一代码块而发生。

静态成员和静态构造函数

在类的类构造函数（C# 中的 static 构造函数、Visual Basic 中的 Shared Sub New）完成运行以前，该类不会初始化。为防止对未初始化的类型执行代码，在类构造函数完成运行以前，公共语言运行库会禁止从其余线程到类的 static 成员（Visual Basic 中的 Shared 成员）的全部调用。

例如，若是某个类构造函数启动了一个新线程，而且该线程过程调用了该类的 static 成员，则在该类构造函数完成以前，会一直禁止新线程。

以上状况适用于可拥有 static 构造函数的任意类型。

通常性建议

使用多线程时要考虑如下准则：

• 不要使用 Thread.Abort 终止其余线程。对另外一个线程调用 Abort 无异于引起该线程的异常，也不知道该线程已处理到哪一个位置。

• 不要使用 Thread.Suspend 和 Thread.Resume 来同步多个线程的活动。不要使用 Mutex、ManualResetEvent、AutoResetEvent 和 Monitor。

• 不要从主程序中控制辅助线程的执行（如使用事件），而应在设计程序时让辅助线程负责等待任务，执行任务，并在完成时通知程序的其余部分。若是辅助线程不阻止，请考虑使用线程池线程。Monitor.PulseAll 在辅助线程阻止的状况下会颇有用。

• 不要将类型用做锁定对象。例如，避免在 C# 中使用 lock(typeof(X)) 代码，或在 Visual Basic 中使用 SyncLock(GetType(X)) 代码，或将 System.Threading.Monitor.Enter(System.Object)和 Type 对象一块儿使用。对于给定类型，每一个应用程序域只有一个 System.Type 实例。若是您锁定的对象的类型是 public，您的代码以外的代码也可锁定它，但会致使死锁。有关其余信息，请参见可靠性最佳作法。

• 锁定实例时要谨慎，例如，C# 中的 lock(this) 或 Visual Basic 中的 SyncLock(Me)。若是您的应用程序中不属于该类型的其余代码锁定了该对象，则会发生死锁。

• 必定要确保已进入监视器的线程始终离开该监视器，即便当线程在监视器中时发生异常也是如此。C# 的 lock 语句和 Visual Basic 的 SyncLock 语句可自动提供此行为，它们用一个 finally 块来确保调用 Monitor.Exit。若是没法确保调用 Exit，请考虑将您的设计更改成使用 Mutex。Mutex 在当前拥有它的线程终止后会自动释放。

• 必定要针对那些须要不一样资源的任务使用多线程，避免向单个资源指定多个线程。例如，任何涉及 I/O 的任务都会从其拥有其本身的线程这一点获得好处，由于此线程在 I/O 操做期间将阻止，从而容许其余线程执行。用户输入是另外一种可从专用线程获益的资源。在单处理器计算机上，涉及大量计算的任务可与用户输入和涉及 I/O 的任务并存，但多个计算量大的任务将相互竞争。

• 对于简单的状态更改，请考虑使用 Interlocked 类的方法，而不是 lock 语句（在 Visual Basic 中为 SyncLock）。lock 语句是一个优秀的通用工具，可是 Interlocked 类为必须是原子性的更新提供了更好的性能。若是没有争夺，它会在内部执行一个锁定前缀。在查看代码时，请注意相似于如下示例所示的代码。在第一个示例中，状态变量是递增的：

  lock(lockObject) 
  {
      myField++;
  }

  可使用 Increment 方法代替 lock 语句，从而提升性能，以下所示：

  System.Threading.Interlocked.Increment(myField);

   

  注意
  在 .NET Framework 2.0 版中，Add 方法提供增量大于 1 的原子更新。

  在第二个示例中，仅当引用类型变量为空引用（在 Visual Basic 中为 Nothing）时，它才会被更新。

  if (x == null)
  {
      lock (lockObject)
      {
          if (x == null)
          {
              x = y;
          }
      }
  }

  改用 CompareExchange 方法能够提升性能，以下所示：

  System.Threading.Interlocked.CompareExchange(ref x, y, null);

  注意
  在 .NET Framework 2.0 版中，CompareExchange 方法具备一个泛型重载，可用于对任何引用类型进行类型安全的替换。

类库的建议

在为多线程编程设计类库时，请考虑如下准则：

• 若是可能，请避免同步需求。对于大量使用的代码更应如此。例如，能够将一个算法调整为容忍争用状况，而不是彻底消除争用状况。没必要要的同步会下降性能，而且可能致使出现死锁和争用状况。

• 默认状况下使静态数据（在 Visual Basic 中为 Shared）是线程安全的。

• 默认状况下不要使实例数据是线程安全的。经过添加锁来建立线程安全的代码的作法会下降性能、加重锁争夺，而且可能致使出现死锁。在常见的应用程序模型中，某一时刻只有一个线程执行用户代码，这样可使对线程安全的需求变为最小。出于此缘由，.NET Framework 类库默认状况下不是线程安全的。

• 避免提供可更改静态状态的静态方法。在常见的服务器方案中，静态状态在各个请求之间是共享的，这意味着多个线程可在同一时刻执行该代码。这样就有可能出现线程错误。请考虑使用一种设计模式，将数据封装到在各请求之间不共享的实例中。此外，若是同步静态数据，更改状态的静态方法间的调用可致使死锁或冗余同步，从而下降性能。