在多线程应用程序中冻结

Question

我正在尝试创建一个WinForms多线程应用程序,它在两个不同的线程中无休止地生成异常.

一个线程使用GenerateDllNotFoundExc()方法,另一个使用另一个方法,它基本上是相同的,但只是生成另一个异常.

然后,它将异常消息写入队列,然后从队列写入文本框.

然而,GUI总是在1秒后冻结,它会将消息写入文本框并冻结.我尝试调试它,代码本身工作,但GUI冻结.

有人可以给我一个关于我做错的提示吗？

private delegate void GetQueueElem();
private event GetQueueElem getqueuelem;     

private void GenerateDllNotFoundExc()
{
    Action<String> addelem = new Action<String>(AddToQueue);

    string exdll = string.Empty;

    while (shouldgeneratemore)
    {
        try 
        {
            throw new DllNotFoundException();
        }
        catch (Exception ex) 
        {
            exdll = ex.Message;
        }

        this.Invoke(addelem, exdll);
    }
}

private void AddToQueue(string exmess)
{            
    lock (lockobject)            
        queue.Enqueue(exmess);

    getqueuelem.Invoke();
}        

private void AddToTextBox()
{           
     while (queue.Count > 0)
     {
         string s = queue.Dequeue() +"\t" + Thread.CurrentThread.Name 
             + "\t" + Thread.CurrentThread.ManagedThreadId + "\t";

         lock (lockobject)
             textBox1.Text += s;                
     }                     
}       

Answer 1

这个问题具有教育意义,它显示了所有三个主要线程错误的证据.将它们大致按顺序排列:

1. 线程竞赛错误.当一个线程读取由另一个线程修改的变量时跳闸.需要锁定以避免引起问题.此代码使用lock关键字但未正确使用它.Queue类不是线程安全的,在此代码中,使用不安全的Count属性和Dequeue()方法都没有锁定.然而,这里不是实际问题,使用Queue的代码实际上并不在多个线程上运行.换句话说,实际上并不需要锁.

2. 僵局.代码以不可预测的顺序获取锁时发生.特别讨厌在程序的UI线程上运行的代码,它经常获取不可见的锁,内置在.NET Framework,操作系统或各种第三方钩子中.屏幕阅读器例如.Invoke()方法特别容易出现死锁,应该强烈避免,BeginInvoke()始终是首选.你实际上并不需要 Invoke(),你不关心返回值.在此程序的实际错误然而,即使它看起来很多像僵局,你可以使用调试器,看看该UI线程执行代码,而不是停在一个锁.

3. 一个消防水带虫.当产生结果的线程比处理它们的线程消耗得快时,就会发生消防.这种bug会产生各种各样的痛苦,它看起来很像僵局.最终,当内存耗尽时,这样的程序总是会崩溃,由包含太多尚未处理的结果的队列消耗.需要一段时间,.NET程序有很多可用的内存.

这是该计划的第3名.UI线程需要执行多个职责并以高优先级处理调用请求.在这种情况下调度调用的方法AddToQueue().它从内部队列读取调用请求,并尝试在执行其他较低优先级任务之前先清空队列.当队列无法清空时会出错,因为工作线程以高于UI线程可以清空队列的速率向队列添加条目.换句话说,UI线程永远不会跟上,它只调度调用请求而不会做任何其他事情.

例如,在任务管理器中非常明显,您将看到您的程序燃烧100%核心.所以你知道它实际上并不是死锁.在你的UI中非常明显,你可以敲击停止按钮,但它没有任何效果.并且绘画不再发生,被视为低优先级任务,只有在没有更重要的事情需要发生时才执行.它看起来完全被冻结,即使UI线程像流氓一样运行.

一个火管软件很容易绊倒,每秒只需要一千多次调用请求.取决于UI线程需要做多少工作.通常很多,更新UI通常非常昂贵.设置TextBox的Text属性没有什么非常微妙的,很多工作都在幕后发生.那个看上去很无辜的+ =操作员会烧掉很多周期.除了SendMessage()的静态开销与本机TextBox通信之外,还经常需要重新分配内部文本缓冲区.比较String和StringBuilder.或者换句话说,即使您最初没有绊倒防火软管错误,也可以保证您迟早会因为TextBox包含太多需要从一个缓冲区移动到另一个缓冲区的文本.在你的情况下更快.

最终像这样的消防水带虫是一个平衡的错误.您正在以远远高于人类可以观察到的速度更新UI .这不是一个有用的用户界面.对于这个程序没有实用的建议,它太合成了,故意放慢工作线程将是一个解决方法.