Invoke和BeginInvoke 区别,InvokeRequired和Invoke

本文深入解析了C#中控件线程安全问题及如何利用Invoke和BeginInvoke方法在不同线程间安全地访问控件。包括执行顺序、同步与异步的区别、如何避免UI线程阻塞以及InvokeRequired属性的作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

转自http://www.cnblogs.com/c2303191/articles/826571.html

Control.Invoke 方法 (Delegate) :拥有此控件的基础窗口句柄的线程上执行指定的委托。

Control.BeginInvoke 方法 (Delegate) :在创建控件的基础句柄所在线程上异步执行指定委托。

(一)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));
  //D代码段......
}
private void invokeMethod(){
  //E代码段
}
private void butInvoke_Click(object sender, EventArgs e) {
   //A代码段.......
   invokeThread = new Thread(new ThreadStart(StartMethod));
   invokeThread.Start();
   //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));
  //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改为更新界面的方法。


InvokeRequired和Invoke

C#中禁止跨线程直接访问控件,InvokeRequired是为了解决这个问题而产生的,当一个控件的InvokeRequired属性值为真时,说明有一个创建它以外的线程想访问它。此时它将会在内部调用new MethodInvoker(LoadGlobalImage)来完成下面的步骤,这个做法保证了控件的安全,你可以这样理解,有人想找你借钱,他可以直接在你的钱包中拿,这样太不安全,因此必须让别人先要告诉你,你再从自己的钱包把钱拿出来借给别人,这样就安全了

------------------------------------------------------------------------

在设计中为了让界面与逻辑分离,我的做法是使用事件,界面只要响应事件来处理界面的显示就行了。而事件在逻辑处理中可能由不同的线程引发,这些事件的响应方法在修改界面中的控件内容时便会引发一个异常。

这时就用到了Control.InvokeRequired 属性 与Invoke方法。

------------------------------------------------------------------------

获取一个值,该值指示调用方在对控件进行方法调用时是否必须调用 Invoke 方法,因为调用方位于创建控件所在的线程以外的线程中。 

如果控件的 Handle 是在与调用线程不同的线程上创建的(说明您必须通过 Invoke 方法对控件进行调用),则为 true;否则为 false。

Windows 窗体中的控件被绑定到特定的线程,不具备线程安全性 。因此,如果从另一个线程调用控件的方法,那么必须使用控件的一个 Invoke 方法来将调用封送到适当的线程。该属性可用于确定是否必须调用 Invoke 方法,当不知道什么线程拥有控件时这很有用。

------------------------------------------------------------------------

首先定义一个委托,与这个事件处理函数的签名一样委托,当然直接使用该事件的委托也是可以的,如:

 

 private   delegate   void  InvokeCallback( string  msg);

然后就是判断这个属性的值来决定是否要调用Invoke函数:

 

 void  m_comm_MessageEvent( string  msg)

    {

     if (txtMessage.InvokeRequired)

     {

     InvokeCallbackmsgCallback  =   new  InvokeCallback(m_comm_MessageEvent);

     txtMessage.Invoke(msgCallback,  new   object []  { msg } );

    } 

     else 

     {

     txtMessage.Text  =  msg;

    } 

   }

说明:这个函数就是事件处理函数,txtMessage是一个文本框。

这样就做到了窗体中控件的线程安全性。

------------------------------------------------------------------------

InvokeRequired 当前线程不是创建控件的线程时为true

比如你可以自己开一个Thread,或使用Timer的事件来访问窗体上的控件的时候,在线程中窗体的这个属性就是True的。

 

简单的说,如果有两个线程,Thread A和Thread B,并且有一个Control c,是在Thread A里面new的。

那么在Thread A里面运行的任何方法调用c.InvokeRequired都会返回false。

相反,如果在Thread B里面运行的任何方法调用c.InvokeRequired都会返回true。

是否是UI线程与结果无关。(通常Control所在的线程是UI线程,但是可以有例外)

 

也可以认为,在new Control()的时候,control用一个变量记录下了当前线程,在调用InvokeRequired时,返回当前线程是否不等于new的时候记录下来的那个线程。


<think>好的,我现在需要回答用户关于C#中InvokeBeginInvoke的用法及区别的问题。首先,我需要回顾一下自己对这些方法的理解,确保准确无误。 InvokeBeginInvoke主要用于在多线程环境中安全地更新UI控件,因为.NET中不允许非创建线程的线程直接修改UI。这涉及到WinForms的线程模型,主UI线程拥有消息循环,负责处理窗口消息,包括控件的更新。如果其他线程直接操作UI控件,可能会导致竞争条件或死锁,所以必须通过InvokeBeginInvoke将调用封送到UI线程执行。 接下来,我需要区分InvokeBeginInvoke的不同点。Invoke是同步的,调用线程会等待UI线程执行完委托后再继续执行。而BeginInvoke是异步的,调用线程不会等待,直接继续执行后续代码。这可能会影响程序的响应性性能,特别是在需要长时间操作时。 然后,我需要考虑它们的用法场景。比如,在需要确保UI更新完成后再进行其他操作时使用Invoke,而在允许后台操作继续执行的同时更新UI时使用BeginInvoke。此外,还需要提到InvokeRequired属性,用来检查当前线程是否是UI线程,从而决定是否需要调用InvokeBeginInvoke。 记得参考提供的引用内容,特别是引用[1]到[5],确保答案中的观点有据可依。例如,引用[2]提到它们是为了安全更新界面显示,引用[3]解释了InvokeRequired的作用,引用[5]提到BeginInvoke返回IAsyncResult推荐使用Invoke来避免线程安全问题。 可能需要注意的细节包括:Control类Delegate类的Invoke/BeginInvoke区别,但用户问题中的引用[1]提到这里讨论的是Control的Invoke,所以应明确说明。此外,要提到BeginInvoke可能导致执行顺序的问题,以及如何处理异步操作完成后的回调。 最后,要组织答案结构,先介绍作用,再对比区别,给出示例代码,并总结应用场景。同时生成相关问题,如性能影响、异步处理方式、InvokeRequired的用途等。</think>### C#中InvokeBeginInvoke的作用与区别 #### 一、核心作用 **Invoke****BeginInvoke**用于在多线程环境中**安全更新UI控件**。由于.NET规定只有创建UI元素的线程(主线程)才能直接修改控件属性,当其他线程需要操作UI时,必须通过这两个方法将操作请求“封送”到UI线程执行[^2][^3]。 #### 二、方法对比 | 特性 | Invoke(同步) | BeginInvoke(异步) | |---------------------|---------------------------------------|----------------------------------------| | **执行方式** | 阻塞调用线程,等待UI线程执行完毕 | 非阻塞,调用后立即返回 | | **返回值** | 直接返回委托执行结果 | 返回`IAsyncResult`用于跟踪异步状态[^5] | | **适用场景** | 需确保UI更新完成后再继续逻辑 | 允许后台线程持续运行,同时触发UI更新 | | **线程安全性** | 高(严格按顺序执行) | 需注意异步操作间的时序问题 | #### 三、代码示例 ```csharp // 同步更新UI this.Invoke(new Action(() => { label1.Text = "同步更新完成"; })); // 异步更新UI IAsyncResult result = this.BeginInvoke(new Action(() => { label1.Text = "异步更新开始"; })); // 可通过result.AsyncWaitHandle.WaitOne()等待完成 ``` #### 四、关键机制 1. **InvokeRequired属性** 用于检测当前线程是否与UI线程相同: ```csharp if (label1.InvokeRequired) { this.Invoke(() => label1.Text = "安全更新"); } else { label1.Text = "直接更新"; } ``` 当返回`true`时,必须通过Invoke/BeginInvoke操作控件。 2. **消息队列机制** BeginInvoke将委托加入UI线程的消息队列,按顺序执行但不保证立即完成[^4]。 #### 五、应用建议 - **优先使用Invoke**:当需要确保UI操作完成后再执行后续逻辑时(如数据提交后的状态更新) - **慎用BeginInvoke**:适用于实时性要求不高的场景(如进度条更新),需配合异常处理避免资源泄漏 - **避免混合使用**:连续多次异步调用可能导致UI更新顺序混乱
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值