C# 多线程同步

C#中的多线程

摩

尔定律已经改变了。计算机仍然在不断变快，不过所倚赖的不再是时钟频率，而是更多的处理器核心。大势所趋，开发者也愈发频繁地处理多线程编程的任务。

多线程编程更加困难，且很容易出错。很多难以察觉的bug都出现在线程的切换过程中。除非仔细检查程序中的每一行代码，并分析线程切换时的各种情况，否则很容易引入潜在的问题。也许有一天，线程的切换发生在了你测试时没有覆盖到的地方，从而导致了程序的崩溃。这样，编写正确的程序变得更加困难，验证程序正确性的难度也大大提高。因此，虽然多线程程序更为流行了，但开发难度仍旧要比单线程程序大得多。

本章并不会让你成为多线程编程的专家，不过其中给出的条目却都是.NET多线程程序设计中的一些常见的建议和规则。若想完整地学习多线程技术的方方面面，我推荐阅读Joe Duffy的Concurrent Programming on Windows Vista: Architecture, Principles, and Patterns（Addison-Wesley, 2008）。在取得以上共识后，下面我们先来看看多线程编程相对于单线程编程所增加的挑战。

简单地将单线程程序转为并行执行将导致很多问题。我们来看一个简单的银行账户的定义。

public class BankAccount

{

    public string AccountNumber

    {

        get;

        private set;

    }

    public decimal Balance

    {

        get;

        private set;

    }

    public BankAccount(string accountNumber)

    {

        AccountNumber = accountNumber;

    }

    public void MakeDeposit(decimal amount)

    {

        Balance += amount;

    }

    public decimal MakeWithdrawal(decimal amount)

    {

        if (Balance > amount)

        {

            Balance -= amount;

            return amount;

        }

        return 0M;

    }

}

如此简单的一段代码，无需过多检查即可保证其正确性。不过在多线程环境中却并非如此。为什么呢？因为上述代码中包含了很多潜在的竞争条件。存款和取款的方法实际上均由几个不同的操作组成。+=操作符首先将当前的账户余额从内存中读取出来并保存于寄存器中。随后CPU将执行相加操作。随后，新的余额才会被写回至内存中。

问题在于，在多核心的处理器上，应用程序中的多个线程可能同时运行于多个核心上。这样，不同的线程就有可能交替地对同一块内存地址进行读写，进而造成数据错误。考虑如下的场景。

(1) 线程A开始存入10 000美元的操作。

(2) 线程A获取到当前的余额为2 000美元。

第2章　C#中的多线程

(3) 线程B开始存入4 000美元的操作。

(4) 线程B获取到当前的余额为2 000美元。

(5) 线程B计算出新的余额为6 000美元。

(6) 线程A计算出新的余额为12 000美元。

(7) 线程A将余额12 000美元保存。

(8) 线程B将余额6 000美元保存。

这样，这种线程之间的交替操作就导致了从前单线程情况下不会发生的错误。

之所以会出现这样的竞争条件，是因为该类中没有为可能引起副作用的操作提供任何同步机制。Deposit()和Withdrawal()方法都会产生副作用：它们均修改了当前的状态，并返回新的值。这两个方法依赖于调用方法时系统的当前状态。例如，若是账户中的余额不足，那么取款操作将失败。没有副作用的方法一般均不需要过多的同步。此类方法不依赖于当前状态，因此在方法执行过程中，即使当前状态发生了改变，也不会影响到其执行结果。

修复这个问题非常简单，只需添加一些锁定即可。

public void MakeDeposit(decimal amount)

{

    lock (syncHandle)

    {

        Balance += amount;

    }

}

public decimal MakeWithdrawal(decimal amount)

{

    lock (syncHandle)

    {

        if (Balance > amount)

        {

            Balance -= amount;

            return amount;

        }

    }

    return 0M;

}

这样似乎解决了问题，不过却可能导致死锁。例如，若某个客户拥有两个银行账户，一个储蓄账户，一个支票账户。客户可能需要进行转账操作——从一个账户中提款，并存入另一个账户中。逻辑上，这是个单一的操作。不过在实现上，它却包含了一系列的操作。首先从一个账户中取款（这本身也是个多步的操作），随后存入另一个账户（也是个多步操作）中。这似乎不会有什么问题：在从一个账户中取款时锁定该账户，然后获取第二个账户的锁定，并执行存款操作。

不过若是多个线程在同时执行转账操作，那么就可能发生死锁。死锁将会发生的情况是，两个线程互相持有另一个线程完成工作所需要的锁。这样，无论等待多长时间，情况都不会有所转变。应用程序看起来就像是崩溃了。实际上并没有崩溃，不过却在等待着一些永远都不会发生的事情。

另一种比死锁略微好一点的情况是活锁。活锁涉及一种较为复杂的锁定机制，这种机制把对同一块数据的读取和写入区分对待。这种机制允许让多个读取线程同时检查一块数据，不过同时仅允许一个写入线程修改该数据。此外，当某一写入线程在修改数据时，也不允许读取线程读取该数据。活锁将发生于这样的情况下：不停有读取线程在检查某块数据，而让写入线程无法插入到其中。这样，该数据实际上就变为了只读的。

没有什么好的方法可以避免此类问题。多线程编程本身就很复杂，所有操作的复杂性也有了很大的提高。不过多线程编程前景广阔，因此每个C#开发人员至少都需要对多线程技术有一些基本的了解。

.NET Framework在很多地方都使用到了多线程。例如在Web应用程序和Web服务中，每个请求都由一个专门的ASP.NET工作线程负责。remoting类库也用同样的方式处理每个请求。有些计时器的事件处理程序运行于新的线程之上。WCF（Windows Communication Foundation）类库也使用了多个线程。你还可以在调用Web服务时采用异步的方式。

你总会用到上述这些技术。因此若想对.NET有更深入的理解，那么必须了解一些多线程技术。

条目11：使用线程池而不是创建线程

你无法知道应用程序中需要的线程的最佳数量。你的应用程序可能运行于拥有多个核心的计算机上，不过无论你今天假设将会有多少个核，6个月后都十有八九会不正确。此外，你也无法控制CLR为完成其自身工作（例如垃圾收集器等）所创建的线程的数量。在服务器应用程序中，例如ASP.NET或WCF服务，每个请求都由一个不同的线程处理。作为应用程序或类库开发者的我们，将很难优化目标系统上的线程数量。但.NET线程池却能够获取到所有的必要信息，来优化指定系统上活动线程的数量。此外，即使你创建了过多的任务或线程，那么线程池也能用队列把无法及时处理的请求保存起来，直至有线程释放出来。

.NET线程池能够替你完成很多线程资源的管理工作。当应用程序开始执行重复的后台任务，且并不需要经常与这些任务交互时，使用.NET线程池管理这些资源将会让程序的性能更佳。

调用QueueUserWorkItem方法即可让线程池来为你管理资源。在其中添加项目之后，该项目将在有空余线程时得以执行。根据正在运行的任务的数量和线程池的大小，项目可能会立即执行，或等待直至有空余的线程出现。线程池由每个处理器中一定数量的就绪线程和一系列I/O读取线程组成。具体的数字因版本的不同而不同。在开始向队列中插入新的任务时，线程池可能会创建更多的线程，这也取决于当前内存以及其他资源的可用情况。

这里并没有仔细解释线程池的实现，因为线程池本身是用来减轻我们的工作，并让框架去帮我们分担的。简而言之，线程池中的线程数量将在可用线程数量和最小化已分配但尚未使用的资源之间自动平衡。在添加了工作项之后，若当前还有可用线程，那么就会开始执行。线程池的工作是保证尽可能快地提供出可用线程。不过对于你来说，只要发起请求，就不必再担心其内部处理机制了。

线程池同样也会自动管理任务结束后的维护工作。当任务结束之后，线程并不会被销毁，而是返回到可用状态，以便执行其他任务。稍后，该线程可能会被线程池分配去处理另外的任务。接下来的任务并不一定和前面的任务一样，可能为应用程序需要的任何一个较耗时的方法。只需调用QueueUserWorkItem并传入需要的方法，线程池将自动为你管理好所有的一切。

线程池还能够用另一种方法帮你管理运行于其他线程中的任务。所有QueueUserWorkItem使用的线程池中的线程均为后台线程（background thread）。这也就意味着你并不需要在应用程序退出之前手工清理资源。若是应用程序在这些后台线程仍在运行时就退出了，那么系统将停止这些后台任务，并释放所有与应用程序相关的资源。你只需要在退出应用程序之前确保停止了所有非后台线程即可。不过若没有做到这一点，那么应用程序很可能在不做任何事情的时候还占用着资源。

从另一个角度考虑，因为后台线程将在没有任何警告的情况下被终止，因此需要小心其中对系统资源的访问方式，免得当应用程序终止时，让系统停留在不稳定的状态中。很多情况下，当线程终止时，运行时将在该线程上抛出ThreadAbortException异常。而若是应用程序在尚有后台线程运行时突然终止，那么后台线程将不会收到任何通知，而只是被立即终止。因此，若某个线程可能会让系统资源处于不稳定状态中，那么则不要使用后台线程。好在这种情况并不多见。

系统将管理线程池中活动线程的数量。线程池将根据当前可用的系统资源数量来适当地执行任务。若系统负荷已经接近极限，那么线程池将暂停开启新任务。而若是系统并不繁忙，那么线程池将立即开始新任务。我们无需手工编写负载均衡的逻辑，线程池将为你做好这一切。

或许你会认为，同时执行的任务的最佳数量就等于计算机上的CPU内核数量。这虽然不算是个最差的策略，不过却过于简单了一些，基本上也不会是最好的答案。等待时间、对除了CPU之外其他资源的争夺以及其他你无法控制的线程均会影响到应用程序中最佳的线程数量。若创建的线程过少，那么将无法完全利用到系统资源，白白浪费了计算能力。而若是线程数量过多，那么计算机将花费过多的时间在线程调度上，进而影响到线程的实际执行时间，反倒降低了整体效率。

为了给出一些通用的原则，我编写了一个使用“亚历山大港的希罗”（Hero of Alexandria）提出的海伦算法计算平方根的小程序。这些原则均比较通用，因为每种算法都有它自己的特性。在这个程序中，核心算法比较简单，且并不需要与其他线程进行交互。

算法的开始将作一次猜测，取得某个数字的平方根，比如猜测1。若想找到下一个近似值，只需计算出当前猜测和原输入与当前猜测的商的平均值。例如，若想得到10的平方根，首先猜测为1，接下来的猜测为[1 + (10/1)]/2，即5.5。重复上述步骤，直至得到符合条件的正确值即可。其代码如下。

public static class Hero

{

    private const double TOLERANCE = 1.0E-8;

    public static double FindRoot(double number)

    {

        double guess = 1;

        double error = Math.Abs(guess * guess - number);

        while (error > TOLERANCE)

        {

            guess = (number / guess + guess) / 2.0;

            error = Math.Abs(guess * guess - number);

        }

        return guess;

    }

}

为了比较线程池、手工创建线程和单线程三种情况下应用程序的性能，这里我还给出了相应的测试程序，其中将重复多次进行该计算。

private static double OneThread()

{

    Stopwatch start = new Stopwatch();

    start.Start();

    for (int i = LowerBound; i < UpperBound; i++)

    {

        double answer = Hero.FindRoot(i);

    }

    start.Stop();

    return start.ElapsedMilliseconds;

}

private static double ThreadPoolThreads(int numThreads)

{

    Stopwatch start = new Stopwatch();

    using (AutoResetEvent e = new AutoResetEvent(false))

    {

        int workerThreads = numThreads;

        start.Start();

        for (int thread = 0; thread < numThreads; thread++ )

            System.Threading.ThreadPool.QueueUserWorkItem(

                (x) =>

                {

                    for (int i = LowerBound;

                        i < UpperBound; i++)

                    {

                        // 进行计算

                        if (i % numThreads == thread)

                        {

                            double answer = Hero.FindRoot(i);

                        }

                    }

                    // 减少计数器的值

                    if (Interlocked.Decrement(

                        ref workerThreads) == 0)

                    {

                        // 设置事件

                        e.Set();

                    }

                });

        // 等待信号

        e.WaitOne();

        // 跳出

        start.Stop();

        return start.ElapsedMilliseconds;

    }

}

private static double ManualThreads(int numThreads)

{

    Stopwatch start = new Stopwatch();

    using (AutoResetEvent e = new AutoResetEvent(false))

    {

        int workerThreads = numThreads;

        start.Start();

        for (int thread = 0; thread < numThreads; thread++)

        {

            System.Threading.Thread t = new Thread(

                () =>

                {

                    for (int i = LowerBound;

                        i < UpperBound; i++)

                    {

                        // 进行计算

                        if (i % numThreads == thread)

                        {

                            double answer = Hero.FindRoot(i);

                        }

                    }

                    // 减少计数器的值

                    if (Interlocked.Decrement(

                        ref workerThreads) == 0)

                    {

                        // 设置事件

                        e.Set();

                    }

                });

            t.Start();

        }

        // 等待信号

        e.WaitOne();

        // 跳出

        start.Stop();

        return start.ElapsedMilliseconds;

    }

}

单线程版本非常简单。而两个多线程版本均使用了lambda表达式语法（参考第1章条目6）来定义后台线程将要执行的操作。当然，如条目6中所述，也可以将lambda表达式替换成匿名委托。

System.Threading.ThreadPool.QueueUserWorkItem(

    delegate(object x)

    {

        for (int i = LowerBound; i < UpperBound; i++)

        {

            // 进行计算

            if (i % numThreads == thread)

            {

                double answer = Hero.FindRoot(i);

            }

        }

        // 减少计数器的值

        if (Interlocked.Decrement(

            ref workerThreads) == 0)

        {

            // 设置事件

            e.Set();

        }

    });

若使用显式的方法并显式创建委托的话，需要增加很多代码。因为外部方法中定义的很多局部变量（重置事件、线程数和当前线程的索引）都会被用于内部的后台线程中。而C#编译器则会自动为使用了lambda表达式的内联方法创建一个闭包（参见第4章条目33和第5章条目41），省去了我们的工作。此外，注意labmda表达式语法也可以用于多语句的方法，而不仅限于单一的表达式中。

主程序为三个版本的算法均统计了时间，这样可以看到使用线程给算法带来的影响。图2-1即为统计结果。从该示例中，我们可以学到一些东西。首先，与线程池线程相比，手工创建线程的开销更大。若创建了10个以上的线程，那么过多的线程将成为最主要的性能瓶颈。即使在这个并不需要太多等待时间的算法中，其影响也显而易见。

每100 000次 计算所用的 时间（ms）

线程数量（多线程算法）

手工线程

线程池

单一线程

    

图2-1　单线程、使用System.Threading.Thread和使用System.Threa- ding.ThreadPool.QueueUserWorkItem程序的计算时间结果。y轴为在一台双核笔记本电脑上执行100 000次计算所花费的时间（单位为ms）

若使用线程池，那么必须添加40个以上的项目，才会看到额外开销逐渐占据了支配地位。而这只是在一台双核的笔记本电脑上而已。对于那些服务器级别的计算机，更多的核心将支持更多的并发线程。让线程数量多于内核数量通常将带来更好的结果。不过，其实际效果非常依赖于应用程序本身，还依赖于应用程序线程花费在等待资源上的时间。

之所以线程池实现要优于手工创建线程，主要有两个因素。首先，线程池将重用那些被释放了的线程。而在手工创建线程时，必须为每个任务创建一个全新的线程。线程的创建和销毁所花费的时间要高于.NET线程池管理所带来的开销。

第二，线程池将为你管理活动线程的数量。若创建了过多的线程，那么系统将挂起一部分，直到有足够的资源执行。QueueUserWorkItem则将工作交给线程池中接下来的一个可用线程，并帮你完成一定的线程管理工作。若应用程序线程池中所有的线程均被占用，那么线程池也会挂起任务，直至出现可用线程。

随着多核处理器的一天天普及，你会越来越频繁遇到多线程的应用程序。若你在开发.NET服务器端应用程序，例如WCF、ASP.NET或.NET远程处理，那么则已经开始与多线程打交道了。这些.NET子系统均使用线程池来管理线程，因此你也应该采用同样的做法。线程池能够降低额外开销，进而提高性能。此外，.NET线程池也能够帮你更好地管理当前用于执行工作的活动线程数量。

 

条目12：使用BackgroundWorker实现线程间通信

条目11演示了使用ThreadPool.QueueUserWorkItem来执行多个后台任务。该API非常易于使用，因为大多数的线程管理工作都交给了框架和底层的操作系统来完成。其中的很多功能也能够重用，因此若在应用程序中需要使用到后台线程来执行任务的话，那么QueueUserWorkItem将是你首要考虑使用的工具。但对于将要执行的后台任务，QueueUserWorkItem有着几个假设。若是程序的实际需求不符合这些假设，那么还是需要额外的工作。不过不是直接使用System.Threading.Thread来创建线程，而是使用System.Compon- entModel.BackgroundWorker。BackgroundWorker不仅构造于ThreadPool之上，还为线程间通信提供了很多支持。

其中需要处理的最重要的问题就是在WaitCallback中抛出的异常。WaitCallback即为实际执行任务的后台线程，若是该方法中有任何异常抛出，那么系统将终止应用程序，而不仅仅是终止该后台线程。这个行为和其他后台线程API的行为一致，不过处理的难点在于，QueueUserWorkItem并没有提供任何内建的错误处理机制。

此外，QueueUserWorkItem也没有提供实现后台线程和前台线程之间交互的内建支持——你不能检查完成情况、跟踪进度、暂停任务或是取消任务。若程序需要这些功能，那么则要使用建立在QueueUserWorkItem功能之上的BackgroundWorker组件。

BackgroundWorker组件包含了System.ComponentModel.Component的功能，用来提供设计时的支持。不过在没有设计器支持时，BackgroundWorker在代码中也非常有用。实际上，我在使用BackgroundWorker的大多数情况时，都不是在Windows窗体中。

BackgroundWorker的最简单使用方法是创建一个符合委托签名的方法，将该方法附加到BackgroundWorker的DoWork事件上，然后调用Background- Worker的RunWorkerAsync()方法。

BackgroundWorker backgroundWorkerExample =

    new BackgroundWorker();

backgroundWorkerExample.DoWork += new

    DoWorkEventHandler(backgroundWorkerExample_DoWork);

backgroundWorkerExample.RunWorkerAsync();

// 其他位置：

void backgroundWorkerExample_DoWork(object sender,

    DoWorkEventArgs e)

{

    // 方法的内容省略

}

在这个模式中，BackgroundWorker提供的功能和ThreadPool.Queue- UserWorkItem完全一致。BackgroundWorker将使用ThreadPool执行其后台任务，其内部也会用到QueueUserWorkItem。

BackgroundWorker的强大之处在于，其整套框架已经为一些常见的场景提供了支持。例如，BackgroundWorker使用事件在前台和后台线程之间通信。当前台线程发起一个请求时，BackgroundWorker将触发后台线程上的DoWork事件。随后DoWork事件的处理程序将读取其参数，并开始相应的执行工作。

在后台线程任务结束（即DoWork事件处理函数执行完成）之后，Back- groundWorker将在前台线程中触发RunWorkerCompleted事件，如图2-2所示。这样，前台线程即可根据需要在后台线程结束时执行必要的后续处理。

图2-2　BackgroundWorker类能够在后台线程执行完毕时触发前台线程中的事件处理程序。只要注册了完成事件，那么在DoWork委托完成执行之后，BackgroundWorker就会触发该事件

除了BackgroundWorker触发的事件，也可以用属性来维护控制前台线程和后台线程间的交互。WorkerSupportsCancellation属性让Background- Worker知道后台线程是否能够中止该操作并退出。WorkerReportsProgress属性则会告知BackgroundWorker对象，每过一段时间后台线程将会通知前台线程其执行进度，如图2-3所示。此外，BackgroundWorker还能将取消请求从前台线程转发给后台线程。这样，后台线程即可检查CancellationPending标记，并根据需要停止执行。

图2-3　BackgroundWorker支持使用多个事件来取消执行任务，向前台线程报告执行进度以及错误报告。BackgroundWorker定义了线程间通信的协议，并在需要的时候通过事件来支持通信机制。若想报告执行进度，那么后台线程必须触发定义在BackgroundWorker中的事件。前台线程的代码也必须支持此类事件，提供必要的事件处理程序

此外，BackgroundWorker还拥有内建的协议来支持报告后台线程中发生的错误。在条目11中，我曾经解释过异常不能从某个线程抛到另一个线程中。若是后台线程中抛出了异常，且没有被捕获，那么该线程将被终止。不仅如此，前台线程也不会收到任何有关后台线程已被终止的通知。BackgroundWorker通过在DoWorkEventArgs中添加Error属性，并将异常信息保存在其中来解决了这个问题。后台线程可以捕获所有的异常，并将其设置到Error属性中。（需要注意的是，这是仅有的几个需要捕获所有异常的场景之一。）随后在后台线程返回时，前台线程即可在事件处理程序中处理该异常。

前面曾提到过，我经常在非Form类中使用BackgroundWorker，甚至在非Windows窗体中，例如服务或Web服务等。不过有几点注意之处。当Backgro- undWorker检测到其正运行于Windows窗体程序中，且该窗体为可见，那么ProgressChanged和RunWorkerCompleted事件将通过转发控制以及Control.BeginInvoke被转发给GUI线程中（参见本章条目16）。在其他情况下，这些委托只是运行于线程池中的某个空闲线程上。在条目16中你将看到，这个行为可能会影响到接收到事件的顺序。

最后一点，因为BackgroundWorker构建于QueueUserWorkItem之上，所以我们可以使用BackgroundWorker来处理多个后台请求。通过检查BackgroundWorker的IsBusy属性即可判断BackgroundWorker当前是否在执行任务。若需要同时执行多个后台任务，那么可以创建多个BackgroundWorker对象。这些BackgroundWorker对象均会共享同一个线程池，因此其实际的执行效果和QueueUserWorkItem一样。这样就需要保证事件处理程序要访问到正确的线程，以便保证后台线程和前台线程之间通信的正确性。

BackgroundWorker支持创建后台任务时的很多常用模式。借助于BackgroundWorker，我们即可提高代码的重用性，根据需要使用这些模式，而并不用手工定义前后台线程之间的通信协议。

 

条目13：让lock()作为同步的第一选择

线程之间需要进行通信。我们需要提供一种安全的方式，让应用程序中的线程能够发送并接收数据。不过，在线程间共享数据可能会引发同步问题，导致数据完整性方面的错误。因此，必须保证每一块共享数据的当前状态都是一致的。实现该目标需要使用同步原语（synchronization primitive）来保护对同享数据的访问。同步原语能够保证在完成一系列必要操作之前，当前线程不会被打断。

.NET BCL中提供了很多不同的同步原语，均可用来保证共享数据的同步。不过仅有一对——Monitor.Enter()和Monitor.Exit()——在C#语言上得到了原生支持。Monitor.Enter()和Monitor.Exit()共同组成了一个临界区。临界区在保证同步方面的应用非常广泛，因此语言本身就对其提供了支持——lock()语句。这样，我们应该尽可能遵循语言设计者的意愿，让lock()作为保证同步的第一选择。

原因很简单：编译器生成的代码永远是一致的，而开发者则可能会犯错误。C#语言引入了lock关键字来控制多线程程序的同步操作。lock语句将生成与正确使用Monitor.Enter()和Monitor.Exit()同样的代码。此外，该关键字更见简单，且能够自动生成所需的可以安全处理异常的代码。

不过，在两种情况下，Monitor也能提供两种lock()无法实现的功能。首先，lock必须使用在同一个上下文中。也就是说，在使用lock时，你无法在一个上下文中进入锁定却在另一个上下文中退出。例如，无法在某个方法中进入Monitor，然后在该方法中的某个lambda表达式中退出（参见第5章条目41）。其次，Monitor.Enter支持制定一个超时时间，这一点将在稍后介绍。

按如下方式使用lock语句即可锁定某一引用类型。

public int TotalValue

{

    get

    {

        lock(syncHandle)

        {

            return total;

        }

    }

}

public void IncrementTotal()

{

    lock (syncHandle)

    {

        total++;

    }

}

lock语句将独占地锁定某一对象，并确保在锁定被释放之前其他线程无法再次锁定。上述使用lock()的示例代码将生成与下面使用Monitor.Enter()和Monitor.Exit()代码同样的IL。

public void IncrementTotal()

{

    object tmpObject = syncHandle;

    System.Threading.Monitor.Enter(tmpObject);

    try

    {

        total++;

    }

    finally

    {

        System.Threading.Monitor.Exit(tmpObject);

    }

}

为了避免常见错误，lock语句还提供了很多检查，例如检查被锁定对象为引用类型。而Monitor.Enter则并没有包含这些检查。如下这段使用lock()的代码无法通过编译。

public void IncrementTotal()

{

    lock (total) // 编译期错误：无法锁定值类型

    {

        total++;

    }

}

不过如下代码则可以编译通过。

public void IncrementTotal()

{

    // 并没有真正锁定住total

    // 锁住的是total的一个装箱对象

    Monitor.Enter(total);

    try

    {

        total++;

    }

    finally

    {

        // 会抛出异常

        // 释放了包含total的另一个装箱对象

        Monitor.Exit(total);

    }

}

之所以Monitor.Enter()可以通过编译，是因为其签名接受的是System. Object对象，因此程序将把total装箱成对象传入。这样，Monitor.Enter()实际上锁定的是total的一个装箱对象，因此埋下了一个潜在的bug。假设第一个线程进入到了IncrementTotal()中并获取了锁定。然后在对total进行操作时，第二个线程也调用了IncrementTotal()。这时，第二个线程依旧可以成功地获取锁定，因为total可被装箱成另外一个对象。第一个线程获取了total的一个装箱，第二个线程则获取了total的另一个装箱。可以看到，这样做不但增加了代码，也没有实现保证同步所需的要求。

这段代码中还有一个bug：在任意一个线程尝试释放total上的锁时，Mon- itor.Exit()均会抛出SynchronizationLockException异常。这是因为调用Monitor.Exit()时total又被装箱到了另外的一个新对象中，因为Monitor. Exit()接受的也是System.Object类型。在释放锁时，释放的对象和开始时锁定的对象并不是同一个，自然也就导致Monitor.Exit()调用失败并抛出异常。

或许有人聪明一些，想出了这样的做法。

public void IncrementTotal()

{

    // 同样无法正常执行：

    object lockHandle = total;

    Monitor.Enter(lockHandle);

    try

    {

        total++;

    }

    finally

    {

        Monitor.Exit(lockHandle);

    }

}

虽然这段代码不会抛出异常，不过也不能保证共享数据的同步。每次调用IncrementTotal()时，均会为total创建一个新的装箱，并锁定该对象。这样，每个线程都能立即获取到所需要的锁，但是却没有锁定到任何共享的资源上。导致的结果就是，虽然每个线程都不会阻塞，但total却无法保持一致。

lock还能预防一些比较易于忽视的问题。Enter()和Exit()是两个独立的调用，很容易写错，导致获取和释放的是两个不同的对象。这将导致SynchronizationLockException。而若是需要锁定多个对象，那么也很有可能在临界区结束时释放了错误的对象。

lock语句还能够自动地生成能够安全处理异常的代码，而这些往往是开发者所忽视的。此外，它生成的代码也要比Monitor.Enter()和Monitor.Exit()更加高效，因为其只需要对目标对象进行一次求值。因此在默认情况下，我们应该在C#程序中尽可能地使用lock语句来保证同步性。

不过，lock语句所生成的MSIL也存在着局限：Monitor.Enter()将在获取到锁之前永远等待下去。这样就可能造成死锁。在大规模的企业系统中，访问关键资源的策略应该更加小心仔细、趋于保守。这时，使用Monitor.TryEnter()即可给出一个等待的超时时间，并给出无法访问到关键资源时的处理方法。

public void IncrementTotal()

{

    if (!Monitor.TryEnter(syncHandle, 1000)) // 等待1s

        throw new PreciousResourceException

            ("Could not enter critical section");

    try

    {

        total++;

    }

    finally

    {

        Monitor.Exit(syncHandle);

    }

}

还可使用泛型类对其进行简单包装。

public sealed class LockHolder : IDisposable

    where T : class

{

    private T handle;

    private bool holdsLock;

    public LockHolder(T handle, int milliSecondTimeout)

    {

        this.handle = handle;

        holdsLock = System.Threading.Monitor.TryEnter(

            handle, milliSecondTimeout);

    }

    public bool LockSuccessful

    {

        get { return holdsLock; }

    }

    #region IDisposable Members

    public void Dispose()

    {

        if (holdsLock)

            System.Threading.Monitor.Exit(handle);

        // 不要重复释放

        holdsLock = false;

    }

    #endregion

}

随后这样使用该泛型类。

object lockHandle = new object();

using (LockHolder