浅谈.NET下的多线程和并行计算：Winform中多线程编程基础

首先我们创建一个Winform的应用程序，在上面添加一个多行文本框和一个按钮控件，按钮的事件如下：

Thread.Sleep(1000);
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 10000; i++)
    sb.Append("test");
string s = sb.ToString();
textBox1.Text = s;

首先我们可以把这个操作理解为一个非常耗时的操作，它至少占用1秒的时间。在1秒后，我们整了一个大字符串作为文本框的值，然后在标签上显示给文本框赋值这个UI渲染行为需要的时间，程序执行结果如下：

我们可以感受到，在点击了按钮之后整个程序的UI就卡住了，没有办法拖动没有办法改变大小，用于体验非常差。一般能想到会新建一个线程来包装这个方法，使得UI线程不被卡住：

new Thread(() =>
{
    Thread.Sleep(1000);
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < 10000; i++)
        sb.Append("test");
    string s = sb.ToString();
    textBox1.Text = s;
}).Start();

使用调试方式运行程序的话会得到如下的异常（非调试方式不会）：

虽然我们知道这样设置：

Control.CheckForIllegalCrossThreadCalls = false;

可以屏蔽这个错误，但是在非创建控件的线程去更新控件的状态的做法会导致很多问题，比如死锁和控件部分被更新等。微软推荐我们使用Control的Invoke或BeginInvoke方法来把涉及到控件状态更新的操作让UI线程去做：

new Thread(() =>
{
    Invoke(new Action(() =>
    {
        Thread.Sleep(1000);
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < 10000; i++)
            sb.Append("test");
        string s = sb.ToString();
        textBox1.Text = s;
    }));
}).Start();

你可能会想到这么写，但是运行程序后可以发现界面依然是卡死。想一下，虽然我们新开了一个线程，但是马上又把整个代码段交给UI线程去做了，当然起不到效果。其实这个方法的工作可以分为两部分，一部分是我们数据的计算，一部分是把计算好的数据显示在界面上，我们只应该把真正和UI相关的操作放到Invoke中让UI线程去做：

new Thread(() =>
{
    Thread.Sleep(1000);
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < 10000; i++)
        sb.Append("test");
    string s = sb.ToString();
    Invoke(new Action(() =>
    {
        textBox1.Text = s;
    }));
}).Start();

再测试一次可以发现，UI在前1秒多的时间没有卡死，在最后的一点时间还是卡死了。您可能会想到，Control还提供了一个BeginInvoke方法，我们来试试看：

new Thread(() =>
{
    Thread.Sleep(1000);
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < 10000; i++)
        sb.Append("test");
    string s = sb.ToString();
    BeginInvoke(new Action(() =>
    {
        textBox1.Text = s;
    }));
}).Start();

好像效果上还是没什么区别，那么Invoke和BeginInvoke的区别在哪里呢？

我们知道Windows应用程序基于消息，Windows API提供了SendMessage和PostMessage两个API，前者执行消息后返回（不经过消息管道，先于PostMessage执行），后者把消息发送到管道异步执行。Invoke和BeginInvoke从行为上来说类似这两个API，但是实际上两者都使用了PostMessage，前者使用信号量在消息执行前阻塞，达到同步的效果。我们来做一个实验：

new Thread(() =>
{
    Thread.Sleep(1000);
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < 10000; i++)
        sb.Append("test");
    string s = sb.ToString();
    Stopwatch sw = Stopwatch.StartNew();
    Invoke(new Action(() =>
    {
        textBox1.Text = s;
    }));
    MessageBox.Show(sw.ElapsedMilliseconds.ToString());
}).Start();

运行程序：

可以体会到，在文本框的值出现之后才出现弹出框，文本框赋值这个消息的执行过程耗时2秒。把Invoke改为BeginInvoke其它不动再执行程序：

明显感到弹出框先显示2秒后文本框的值出现。BeginInvoke没有阻塞后续语句的执行。

现在您可能还有疑问为什么使用了BeginInvoke，UI还是卡了大概2秒，可以这么理解，我们把这么多的文字赋值到文本框中，这个UI行为是非常耗时的，不管是Invoke还是BeginInvoke最终是发送消息给UI线程处理（两者都没有使用线程池），它就是需要这么多时间。

一般来说我们能做的优化是：

1） 尽量把非UI的操作使用新的线程去异步计算，不阻塞UI线程，真正需要操作UI的时候才去提交给UI线程

2） 尽量减少UI的操作复杂度，比如如果需要在UI上绘制一个复杂图形可以在内存中先创建一个位图，绘制好之后把整个位图在UI上绘制，而不是直接在UI上绘制这个图形。

作者： lovecindywang

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12639172/viewspace-624441/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/12639172/viewspace-624441/