c#多線程(UI線程,控件顯示更新) Invoke和BeginInvoke 區別

若是隻是直接使用子線程訪問UI控件,直接看內容三,若是想深刻了解從內容一看起。html

 

1、Control.Invoke和BeginInvoke方法的區別數據庫

先上總結:安全

Control.Invoke 方法 (Delegate) :擁有此控件的基礎窗口句柄的線程上執行指定的委託。但委託的內容在UI線程上執行。網絡

Control.BeginInvoke 方法 (Delegate) :在建立控件的基礎句柄所在線程上異步執行指定委託。但委託的內容在UI線程上執行。多線程

 

(一)Control的Invoke和BeginInvoke
咱們要基於如下認識:
(1)Control的Invoke和BeginInvoke與Delegate的Invoke和BeginInvoke是不一樣的。
(2)Control的Invoke和BeginInvoke的參數爲delegate,委託的方法是在Control的線程上執行的,也就是咱們平時所說的UI線程。

咱們以代碼(一)來看(Control的Invoke)
private delegate void InvokeDelegate();
private void InvokeMethod(){
   //C代碼段
}
private void butInvoke_Click(object sender, EventArgs e) {
   //A代碼段.......
   this.Invoke(new InvokeDelegate(InvokeMethod));
   //B代碼段......
}
你以爲代碼的執行順序是什麼呢?記好Control的Invoke和BeginInvoke都執行在主線程即UI線程上
A------>C---------------->B
解釋:(1)A在UI線程上執行完後,開始Invoke,Invoke是同步
(2)代碼段B並不執行,而是當即在UI線程上執行InvokeMethod方法,即代碼段C。
(3)InvokeMethod方法執行完後,代碼段C纔在UI線程上繼續執行。

看看代碼(二),Control的BeginInvoke
private delegate void BeginInvokeDelegate();
private void BeginInvokeMethod(){
   //C代碼段
}
private void butBeginInvoke_Click(object sender, EventArgs e) {
   //A代碼段.......
   this.BeginInvoke(new BeginInvokeDelegate(BeginInvokeMethod));
   //B代碼段......
}

你以爲代碼的執行順序是什麼呢?記好Control的Invoke和BeginInvoke都執行在主線程即UI線程上
A----------->B--------------->C慎重,這個只作參考。。。。。,我也不願定執行順序,若是有哪位達人知道的話請告知。
解釋::(1)A在UI線程上執行完後,開始BeginInvoke,BeginInvoke是異步
(2)InvokeMethod方法,即代碼段C不會執行,而是當即在UI線程上執行代碼段B。
(3)代碼段B執行完後(就是說butBeginInvoke_Click方法執行完後),InvokeMethod方法,即代碼段C纔在UI線程上繼續執行。

由此,咱們知道:
Control的Invoke和BeginInvoke的委託方法是在主線程,即UI線程上執行的。也就是說若是你的委託方法用來取花費時間長的數據,而後更新界面什麼的,千萬別在UI線程上調用Control.Invoke和Control.BeginInvoke,由於這些是依然阻塞UI線程的,形成界面的假死。

那麼,這個異步究竟是什麼意思呢?

異步是指相對於調用BeginInvoke的線程異步,而不是相對於UI線程異步,你在UI線程上調用BeginInvoke ,固然不行了。----摘自"Invoke和BeginInvoke的真正涵義"一文中的評論。
BeginInvoke的原理是將調用的方法Marshal成消息,而後調用Win32 API中的RegisterWindowMessage()向UI窗口發送消息。----摘自"Invoke和BeginInvoke的真正涵義"一文中的評論。

(二)咱們用Thread來調用BeginInvoke和Invoke
      咱們開一個線程,讓線程執行一些耗費時間的操做,而後再用Control.Invoke和Control.BeginInvoke回到用戶UI線程,執行界面更新。

代碼(三)  Thread調用Control的Invoke
private Thread invokeThread;        
private delegate void invokeDelegate();   
private void StartMethod(){
   //C代碼段......
   Control.Invoke(new invokeDelegate(invokeMethod)); 
併發

【上面這句話做用是把消息發送給UI線程,而後在這個點阻塞,等UI線程處理完髮送的消息後才繼續往下執行,特別適合阻塞更新UI控件】異步

  //D代碼段......
}
private void invokeMethod(){
  //E代碼段
}
private void butInvoke_Click(object sender, EventArgs e) {
   //A代碼段.......
   invokeThread = new Thread(new ThreadStart(StartMethod));
ui

   invokeThread.Start();this

   //B代碼段......
}

你以爲代碼的執行順序是什麼呢?記好Control的Invoke和BeginInvoke都執行在主線程即UI線程上
A------>(Start一開始B和StartMethod的C就同時執行)---->(C執行完了,無論B有沒有執行完,invokeThread把消息封送(invoke)給UI線程,而後本身等待)---->UI線程處理完butInvoke_Click消息後,處理invokeThread封送過來的消息,執行invokeMethod方法,即代碼段E,處理日後UI線程切換到invokeThread線程。
這個Control.Invoke是相對於invokeThread線程同步的,阻止了其運行。

解釋:
1。UI執行A
2。UI開線程InvokeThread,B和C同時執行,B執行在線程UI上,C執行在線程invokeThread上。
3。invokeThread封送消息給UI,而後本身等待,UI處理完消息後,處理invokeThread封送的消息,即代碼段E
4。UI執行完E後,轉到線程invokeThread上,invokeThread線程執行代碼段D

代碼(四)  Thread調用Control的BeginInvoke
private Thread beginInvokeThread;
private delegate void beginInvokeDelegate();
private void StartMethod(){
   //C代碼段......
   Control.BeginInvoke(new beginInvokeDelegate(beginInvokeMethod));spa

【上面這句話做用是把消息發送給UI線程,而後不阻塞繼續往下執行D代碼,也就是再也不管發送的消息了,UI線程處理完本身的事情後會處理這個發送的消息,通常不多用這種方法更新UI控件,由於通常狀況下都要求阻塞次(子)線程更新的UI控件的,只要不阻塞UI主(父)線程,讓用戶感受不到界面死機就行。】

  //D代碼段......
}
private void beginInvokeMethod(){
  //E代碼段
}
private void butBeginInvoke_Click(object sender, EventArgs e) {
   //A代碼段.......
   beginInvokeThread = new Thread(new ThreadStart(StartMethod));
   beginInvokeThread .Start();
   //B代碼段......
}
你以爲代碼的執行順序是什麼呢?記好Control的Invoke和BeginInvoke都執行在主線程即UI線程上
A在UI線程上執行----->beginInvokeThread線程開始執行,UI繼續執行代碼段B,併發地invokeThread執行代碼段C-------------->無論UI有沒有執行完代碼段B,這時beginInvokeThread線程把消息封送給UI,單本身並不等待,繼續向下執行-------->UI處理完butBeginInvoke_Click消息後,處理beginInvokeThread線程封送過來的消息。


解釋:
1。UI執行A
2。UI開線程beginInvokeThread,B和C同時執行,B執行在線程UI上,C執行在線程beginInvokeThread上。
3。beginInvokeThread封送消息給UI,而後本身繼續執行代碼D,UI處理完消息後,處理invokeThread封送的消息,即代碼段E
有點疑問:若是UI先執行完畢,是否是有可能過了段時間beginInvokeThread才把消息封送給UI,而後UI才繼續執行封送的消息E。如圖淺綠的部分。


Control的BeginInvoke是相對於調用它的線程,即beginInvokeThread相對是異步的。
所以,咱們能夠想到。若是要異步取耗費長時間的數據,好比從數據庫中讀大量數據,咱們應該這麼作。
(1)若是你想阻止調用線程,那麼調用代碼(三),代碼段D刪掉,C改成耗費長時間的操做,由於這個操做是在另一個線程中作的。代碼段E改成更新界面的方法。
(2)若是你不想阻止調用線程,那麼調用代碼(四),代碼段D刪掉,C改成耗費長時間的操做,由於這個操做是在另一個線程中作的。代碼段E改成更新界面的方法。

文章轉自:http://www.cnblogs.com/mashang/archive/2009/08/01/1536730.html

 

 

2、有了一點上面的知識,來看「C#多線程異步訪問winform中控件(爲了加深對上面的理解,但還不是最簡單的方法,最簡單的方法見下面)」:

轉自http://blog.csdn.net/ajrm0925/article/details/5314099

咱們在作winform應用的時候,大部分狀況下都會碰到使用多線程控制界面上控件信息的問題。然而咱們並不能用傳統方法來作這個問題,下面我將詳細的介紹。

      首先來看傳統方法:

     public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
        }
        private void Form1_Load(object sender, EventArgs e)
        {
            Thread thread = new Thread(ThreadFuntion);
            thread.IsBackground = true;
            thread.Start();
        }
        private void ThreadFuntion()
        {
            while (true)
            {
                this.textBox1.Text = DateTime.Now.ToString();
                Thread.Sleep(1000);
            }
        }
    }

       運行這段代碼,咱們會看到系統拋出一個異常:Cross-thread operation not valid:Control 'textBox1' accessed from a thread other than the thread it was created on. 這是由於.net 2.0之後增強了安全機制,不容許在winform中直接跨線程訪問控件的屬性。那麼怎麼解決這個問題呢,下面提供幾種方案。

第一種方案,咱們在Form1_Load()方法中加一句代碼:

      private void Form1_Load(object sender, EventArgs e)
       {
            Control.CheckForIllegalCrossThreadCalls = false;
            Thread thread = new Thread(ThreadFuntion);
            thread.IsBackground = true;
            thread.Start();
        }
      加入這句代碼之後發現程序能夠正常運行了。這句代碼就是說在這個類中咱們不檢查跨線程的調用是否合法(若是沒有加這句話運行也沒有異常,那麼說明系統以及默認的採用了不檢查的方式)。然而,這種方法不可取。咱們查看CheckForIllegalCrossThreadCalls 這個屬性的定義,就會發現它是一個static的,也就是說不管咱們在項目的什麼地方修改了這個值,他就會在全局起做用。並且像這種跨線程訪問是否存在異常,咱們一般都會去檢查。若是項目中其餘人修改了這個屬性,那麼咱們的方案就失敗了,咱們要採起另外的方案。

第二種方案,就是使用delegate和invoke來從其餘線程中控制控件信息。網上有不少人寫了這種控制方式,然而我看了不少這種帖子,代表上看來是沒有什麼問題的,可是實際上並無解決這個問題,首先來看網絡上的那種不完善的方式:

public partial class Form1 : Form
    {
        private delegate void FlushClient();//代理
        public Form1()
        {
            InitializeComponent();
        }
        private void Form1_Load(object sender, EventArgs e)
        {
            Thread thread = new Thread(CrossThreadFlush);

             thread.IsBackground=true;
             thread.Start();
        }

        private void CrossThreadFlush()
        {
            //將代理綁定到方法 
            FlushClient fc = new FlushClient(ThreadFuntion);
            this.BeginInvoke(fc);//調用代理 【注意this只Form窗體,因此也是一個Control,具備BeginInvoke方法,而且在UI線程中執行代理fc】
        }
        private void ThreadFuntion()
        {
            while (true)
            {
                this.textBox1.Text = DateTime.Now.ToString();
                Thread.Sleep(1000);
            }
        }
    }

       使用這種方式咱們能夠看到跨線程訪問的異常沒有了。可是新問題出現了,界面沒有響應了。爲何會出現這個問題,咱們只是讓新開的線程無限循環刷新,理論上應該不會對主線程產生影響的。其實否則,這種方式其實至關於把這個新開的線程「注入」到了主控制線程中,它取得了主線程的控制。只要這個線程不返回,那麼主線程將永遠都沒法響應。就算新開的線程中不使用無限循環,使能夠返回了。這種方式的使用多線程也失去了它原本的意義。    

第三種方案,如今來讓咱們看看推薦的解決方案:

public partial class Form1 : Form
    {
        private delegate void FlushClient();//代理
        public Form1()
        {
            InitializeComponent();
        }
        private void Form1_Load(object sender, EventArgs e)
        {
            Thread thread = new Thread(CrossThreadFlush);
            thread.IsBackground = true;
            thread.Start();
        }

        private void CrossThreadFlush()
        {
            while (true)
            {
                //將sleep和無限循環放在等待異步的外面
                Thread.Sleep(1000);
                ThreadFunction();
            }
        }
        private void ThreadFunction()
        {
            if (this.textBox1.InvokeRequired)//等待異步
            {
                FlushClient fc = new FlushClient(ThreadFunction);
                this.Invoke(fc);//經過代理調用刷新方法 【注意this只Form窗體,因此也是一個Control,具備BeginInvoke方法,而且在UI線程中執行代理fc】
            }
            else
            {
                this.textBox1.Text = DateTime.Now.ToString();
            }
        }
    }

       運行上述代碼,咱們能夠看到問題已經被解決了,經過等待異步,咱們就不會老是持有主線程的控制,這樣就能夠在不發生跨線程調用異常的狀況下完成多線程對winform多線程控件的控制了。

 

 

3、最簡單的C#多線程異步訪問winform中控件的方法,其實就是對上面「推薦的方案進行總結和簡化的來的」

轉自:http://blog.csdn.net/ajrm0925/article/details/5314195

private void button1_Click(object sender, EventArgs e)
{
    ThreadStart ts = new ThreadStart(add);
    Thread th = new Thread(ts);
    th.Start(); 【啓動子線程add】
 }

delegate void DelChangText(string ss);  //【先聲明一個代理,是一個類型】

void add()  【這是在子線程中執行的內容】
{
   int a = 1;
   int b = 2;
   string sum = Convert.ToString(a + b);
   // 計算完成須要在一個文本框裏顯示
   this.BeginInvoke(new DelChangText(intoText), sum);  //【從add子線程轉到UI主線程執行intoText方法,這裏也可使用this.Invoke,至於區別見大標題一】

   //或改成intoText(sum);執行結果也正確
}

void intoText(string sum)                     //【再寫對控件進行操做的方法,注意它的通常固定寫法】
{
   if (this.InvokeRequired)  //藉助this即Form對象來判斷正在執行的代碼是否是在UI線程中,若是是在UI線程,則說明沒在異步調用,因此條件爲假
   {
      this.BeginInvoke(new DelChangText(intoText), sum);  //【this是Form控件,因此changText會在UI線程中執行,不懂的看大標題一和二】

   }
   else
   {
      textBox1.Text = sum;
   }
}

 解釋:從上面代碼來看if (this.InvokeRequired)彷佛是多餘的由於子線程add中使用了this.BeginInvoke轉到UI線程中執行inntoText方法,因此if (this.InvokeRequired)條件判斷永遠爲假,但這樣寫安全,誰能保證子線程中開啓的inntoText方法在UI線程中執行呢。

其實能夠把上面add方法中的this.BeginInvoke改成直接執行intoText試試看,是否是進入到if語句中了。此時執行也是正確的。

相關文章
相關標籤/搜索