WindowsFormsSynchronizationContext通过将自身附加到绑定到创建上下文的线程的特殊控件来工作。

所以

 if (foo.InvokeRequired) { foo.BeginInvoke(...) } else { ... } 

可以用更安全的版本替换：

 context.Post(delegate { if (foo.IsDisposed) return; ... }); 

假设context是在foo所在的同一UI线程上创建的WindowsFormsSynchronizationContext 。

此版本避免了您提出的问题：

在非GUI线程执行foo.InvokeRequired之后，foo的状态可以改变。 例如，如果我们在foo.InvokeRequired之后关闭表单，但在foo.BeginInvoke之前，调用foo.BeginInvoke将导致InvalidOperationException：在创建窗口句柄之前，无法在控件上调用Invoke或BeginInvoke。 如果我们在调用InvokeRequired之前关闭表单，则不会发生这种情况，因为即使从非GUI线程调用它也是错误的。

如果您使用多个消息循环或多个UI线程，请注意WindowsFormsSynchronizationContext.Post的一些特殊情况：

如果在自动处理的控件（如主窗体）上IsDisposed则这些情况都不会意外执行代码，因为委托将立即退出，即使它是在意外时间执行的。

危险的情况是调用WindowsFormsSynchronizationContext.Send并考虑代码将被执行：它可能没有，现在有办法知道它是否做了什么。

我的结论是WindowsFormsSynchronizationContext是一个更好的解决方案，只要它被正确使用。

它可以在复杂的情况下创建sublte问题但是常见的GUI应用程序只有一个消息循环，只要应用程序本身一直很好。

谁说InvokeRequired / Control.BeginInvoke是首选？ 如果你问我，在大多数情况下，由于你提到的确切原因，这是一种反模式。 您链接的问题有很多答案，有些确实建议使用同步上下文（包括我的 ）。

虽然任何给定的控件都可以在您尝试从发布的委托访问它时进行处理，但使用Control.IsDisposed可以很容易地解决（因为您的委托在UI线程上执行，因此在运行时没有任何东西可以处理控件）：

上述就是C#学习教程：为什么InvokeRequired比WindowsFormsSynchronizationContext更受欢迎？分享的全部内容，如果对大家有所用处且需要了解更多关于C#学习教程，希望大家多多关注—计算机技术网(www.ctvol.com)!

 public partial class MyForm : Form { private readonly SynchronizationContext _context; public MyForm() { _context = SynchronizationContext.Current //... } private MethodOnOtherThread() { //... _context.Post(status => { // I think it's enough to check the form's IsDisposed // But if you want to be extra paranoid you can test someLabel.IsDisposed if (!IsDisposed) {someLabel.Text = newText;} },null); } }