SynchronizationContext是什么？

Posted 2020-08-21

使用场景， 例如有Thread1和Thread2两个线程，如果需要在Thread2执行的时候在Thread1线程中执行一些代码（UI线程的更新）那么需要Thread2需要做的是拿到Thread1 的SynchronizationContext对象，然后把要执行的代码利用委托的方式通过SynchronzationContext的Post()或者Send()方法来传递给Thread1执行。线程的SynchronizationContext 都是通过SynchronizationContext.Current 这个静态属性获得。 那么是不是每个线程默认都有SynchronizationContext呢？ 并不是， 目前我只知道Winfrom 和WPF 创建Control的时候才会 给主线程的SynchronizationContext赋值。如果线程中没有类似的操作 那就SynchronizationContext是Null。当然我们可以手动给线程设置一个SynchronizationContext，然而我们自己手动设置的并不能起到跨线程调用的神奇效果。原因后面讲先看代码：

【代码1】:线程中的SynchronizationContext 何时会赋值?

class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(SynchronizationContext.Current==null);
            TextBox tb = new TextBox();
            Console.WriteLine("创建Control后");
            Console.WriteLine(SynchronizationContext.Current==null);
            Console.WriteLine(SynchronizationContext.Current);
            Console.ReadKey();
        }
    }

这是一段控制台代码，从执行结果可以看看出在创建Control之前主线程的Synchronization对象是空的,在创建Control之后Synchronization存在了说明Control在创建的时候给Synchronization赋值了。有细心的朋友可能会发打印出来的类名是WindowsFormsSynchronizationContext而不是SynchronizationContext后面会解释这一状况。

【代码2】：我们如何使用SynchronizationContext来实现神奇的跨线程调用委托的功能呢？

class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("主线程：ID=" + Thread.CurrentThread.ManagedThreadId);
            TextBox tb = new TextBox(); //模拟UI线程获取SynchronizationContext对象
            Thread t1 = new Thread(Run);
            t1.Start(SynchronizationContext.Current);
            Console.ReadKey();
        }
        static void Run(object obj)
        {
            Console.WriteLine("线程t1：ID=" + Thread.CurrentThread.ManagedThreadId);
            SynchronizationContext sc = obj as SynchronizationContext;
           sc.Send(Callback, null);
           //sc.Post(Callback, null);
            Console.WriteLine("线程t1完。");
        }
        static void Callback(object obj)
        {
            Console.WriteLine("回调：ID=" + Thread.CurrentThread.ManagedThreadId);
        }
    }

这里有个问题就是不管是Send还是Post 两个都没有执行CallBack这个回调，不同的是Post打印了完成，而Send没有打印完成。那我们就知道了Send同步调用的 代码被阻塞了，Post是异步调用的 没有阻塞线程。其实吧，不管是Send还是Post都是异步调用的区别是有没有用WaitHandle机制来阻塞而已。那么他们到底为什么没有执行回调函数呢？来看看他的源代码。由【代码1】我们可以看出Control创建的时候给主线程赋值了WindowsFormsSynchronizationContext，这个类是SynchronizationContext的子类。

【代码3】

public sealed class WindowsFormsSynchronizationContext : SynchronizationContext, IDisposable
    {
        private Control controlToSendTo;

        private WindowsFormsSynchronizationContext(Control marshalingControl, Thread destinationThread)
        {
            controlToSendTo = marshalingControl;
            this.DestinationThread = destinationThread;
            Debug.Assert(controlToSendTo.IsHandleCreated, "Marshaling control should have created its handle in its ctor.");
        }
        //省略若干代码。。。。。。。

        public override void Send(SendOrPostCallback d, Object state)
        {
            Thread destinationThread = DestinationThread;
            if (destinationThread == null || !destinationThread.IsAlive)
            {
                throw new InvalidAsynchronousStateException(SR.GetString(SR.ThreadNoLongerValid));
            }

            Debug.Assert(controlToSendTo != null, "Should always have the marshaling control by this point");

            if (controlToSendTo != null)
            {
                controlToSendTo.Invoke(d, new object[] { state });
                //Send直接调用Control的Invoke
            }
        }

        public override void Post(SendOrPostCallback d, Object state)
        {
            Debug.Assert(controlToSendTo != null, "Should always have the marshaling control by this point");

            if (controlToSendTo != null)
            {
                controlToSendTo.BeginInvoke(d, new object[] { state });
                //Post直接调用Control的BeginInvoke
            }
        }

        //省略若干代码。。。。。。。
    }

说重点：从代码中可以看出 WindowsFormsSynchronizationContext  继承了SynchronizationContext 并且重写了Post()和Send()方法，而这两个方法的代码也不难懂 Post()方法就是直接调用Control 的BeginInvoke() 而Send就是直接调用了Contorl的Invoke方法。

Control的BeginInvoke 和Invoke我们 都知道 我们跨线程来更新UI的时候就会用到这两个方法，要不然抛异常。他们两个的背后又有着怎样的秘密呢？让我们来继续深挖。

【代码4】

//Control的BeginInvoke方法 都调用了 MarshaledInvoke 只是 最后一个参数不同
        [EditorBrowsable(EditorBrowsableState.Advanced)]
        [SuppressMessage("Microsoft.Security", "CA2123:OverrideLinkDemandsShouldBeIdenticalToBase")]
        public IAsyncResult BeginInvoke(Delegate method, params Object[] args)
        {
            using (new MultithreadSafeCallScope())
            {
                Control marshaler = FindMarshalingControl();
                return (IAsyncResult)marshaler.MarshaledInvoke(this, method, args, false);
            }
        }

        //Control的BeginInvoke方法 都调用了 MarshaledInvoke 只是 最后一个参数不同
        public Object Invoke(Delegate method, params Object[] args)
        {
            using (new MultithreadSafeCallScope())
            {
                Control marshaler = FindMarshalingControl();
                return marshaler.MarshaledInvoke(this, method, args, true);
            }
        }

        //Control的BeginInvoke和Invoke最后都调用了MarshaledInvoke
        private Object MarshaledInvoke(Control caller, Delegate method, Object[] args, bool synchronous)
        {
            //省略若干。。。。
                UnsafeNativeMethods.PostMessage(new HandleRef(this, Handle), threadCallbackMessage, IntPtr.Zero, IntPtr.Zero);
                //PostMessage又是什么东东呢
            //省略若干。。。。

            if (synchronous)
            {
                if (!tme.IsCompleted)
                {
                    WaitForWaitHandle(tme.AsyncWaitHandle);
                    //Control 的BeginInvoke 方法和Invoke方法 的区别就在这里了 
                    //其实他们的委托都是在拥有Control的线程上执行的也就是UI线程
                    //只是Invoke用到了WaitForWaitHandle 来阻塞调用Invoke的线程 而BeginInvoke没有阻塞
                    //从这个就可以看出Begininvoke的异步 并没有创建新的线程，并不是我们想象中的那种异步！！！
                }
                if (tme.exception != null)
                {
                    throw tme.exception;
                }
                return tme.retVal;
            }
            else
            {
                return (IAsyncResult)tme;
            }
        }

        //PostMessage又是什么东东呢？没错他就是WindowsAPI 哈哈 这下算是挖到低了
        //是一个用来发送消息到窗口消息队列的api函数，但这个方法是非阻塞的。也就是它会马上返回，而不管消息是否真的发送到目的地，也就是调用者不会被阻塞。 
        [DllImport(ExternDll.User32, CharSet = CharSet.Auto)]
        [ResourceExposure(ResourceScope.None)]
        public static extern bool PostMessage(HandleRef hwnd, int msg, IntPtr wparam, IntPtr lparam);

    }

那么什么是消息队列呢？

Windows GUI程序是基于消息机制的，有个主线程维护着一个消息泵。这个消息泵让windows程序生生不息。

Windows GUI程序的消息循环

Windows程序有个消息队列，窗体上的所有消息是这个队列里面消息的最主要来源。这里的while循环使用了GetMessage（）这个方法，这是个阻塞方法，也就是队列为空时方法就会被阻塞，从而这个while循环停止运动，这避免了一个程序把cpu无缘无故地耗尽，让其它程序难以得到响应。当然在某些需要cpu最大限度运动的程序里面就可以使用另外的方法，例如某些3d游戏或者及时战略游戏中，一般会使用PeekMessage（）这个方法，它不会被windows阻塞，从而保证整个游戏的流畅和比较高的帧速。

这个主线程维护着整个窗体以及上面的子控件。当它得到一个消息，就会调用DispatchMessage方法派遣消息，这会引起对窗体上的窗口过程的调用。窗口过程里面当然是程序员提供的窗体数据更新代码和其它代码。

【代码5】

public static void Main(string[] args) 
{ 
   Form f = new Form(); 
   Application.Run(f); 
} 
//Dotnet窗体程序封装了上述的while循环，这个循环就是通过Application.Run方法启动的。

现在知道我们【代码2】为什么没有执行回调函数了吧，是的我们就只是创建了一个Control而已 并没有让这个这个程序的消息循环跑起来。那现在让我们对代码而做一些改动，看看是不是就可以执行回掉函数了。

【代码6】

class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("我是主线程我的ID是：" + Thread.CurrentThread.ManagedThreadId);
            Application.SetCompatibleTextRenderingDefault(false);
            // TextBox tb = new TextBox(); //单来这个 不行的 ， 毕竟到最后还是得依赖消息队列 句柄什么的
            Form form = new Form();
            Button btn = new Button();
            btn.Text = "测试";
            btn.Click += Btn_Click;
            form.Controls.Add(btn);
            Application.Run(form);//模拟UI线程获取SynchronizationContext

            Console.ReadKey();
        }
        private static void Btn_Click(object sender, EventArgs e)
        {
            Thread t1 = new Thread(run);
            t1.Start(SynchronizationContext.Current);
        }
        static void run(object obj)
        {
            Console.WriteLine("我是T1线程我的ID是：" + Thread.CurrentThread.ManagedThreadId);
            SynchronizationContext sc = obj as SynchronizationContext;
            sc.Post(doWork, null);
            Console.WriteLine("执行完成");
        }    
        static void doWork(object obj)
        {
            Console.WriteLine("我是t1中使用SynchronizationContext的回调我的ID是:" + Thread.CurrentThread.ManagedThreadId);
        }
    }

果然没错。 回调的线程ID 和主线程的线程ID一致，证明回调是在主线程中执行的。

那么对于两个都不是UI线程的情况呢？ 能不能做到跨线程委托的效果呢？ 由【代码1】我们知道非UI线程中的SynchronizationContext如果不赋值的话那就是null。

所以在调用前要给SynchronizationContext赋值。

【代码7】

class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("主线程：ID=" + Thread.CurrentThread.ManagedThreadId);
            //设置这个线程的SynchronizationContext
            SynchronizationContext.SetSynchronizationContext(new SynchronizationContext());
            Thread t1 = new Thread(Run);
            t1.Start(SynchronizationContext.Current);
            Console.ReadKey();
        }
        static void Run(object obj)
        {
            Console.WriteLine("线程t1：ID=" + Thread.CurrentThread.ManagedThreadId);
            SynchronizationContext sc = obj as SynchronizationContext;
            sc.Send(Callback, null);
            SendOrPostCallback cc = new SendOrPostCallback(Callback);
            Console.WriteLine("线程t1完。");
        }
        static void Callback(object obj)
        {
            Console.WriteLine("回调：ID=" + Thread.CurrentThread.ManagedThreadId);
        }
    }

从执行结果可以看出回调函数打印的线程ID和线程t1的打印的线程ID 一致 ，说明回调并没有在主线程中执行。那这是为啥呢？

看看SynchronizationContext源代码。

【代码8】

public class SynchronizationContext
        {
            //省略若干代码。。。。。。

            //直接调用回调
            public virtual void Send(SendOrPostCallback d, Object state)
            {
                d(state);
            }

            //线程池调用回调
            public virtual void Post(SendOrPostCallback d, Object state)
            {
                ThreadPool.QueueUserWorkItem(new WaitCallback(d), state);
            }
            //省略若干代码。。。。。。
        }

看完代码你会发现 它就是什么都没干！！！ Send就直接调用了。这也就解释了 回调函数打印的线程ID和线程t1的打印的线程ID 一致。

结语：

          SynchronizationContext 只是一个父类而已，从它的Send和Post方法都标记为virtual  可以看出，它仅仅只是作为一个父类而存在，所以直接使用SynchronizationContext是毫无意义的。想要实现一些神奇的功能，你还要自己去重写它。目前MSDN　可以查到的　SynchronizationContext子类有俩个都是和GUI程序有关的看下图

WindowsFormsSynchronizationContext 我们见识过了，DispatcherSynchronizationContext至于这个 是WPF中的　和WindowsFormsSynchronizationContext　功能类似。

参考：

              http://www.cnblogs.com/fuchongjundream/p/3939298.html

             http://www.cnblogs.com/lzxianren/p/SynchronizationContext.html

完！