Azure Worker Role中SynchronizationContext.Current先空后初始化的原因探究

首先可以明确地说：这是预期行为，并非内存泄漏。让我详细拆解背后的原因：

为什么SynchronizationContext.Current会从null变为默认上下文？ #

在控制台、Windows服务或Azure Worker Role这类“无UI”环境中，线程池线程初始状态下的SynchronizationContext.Current确实是null。但.NET框架有一个懒加载机制：当异步操作需要同步上下文（比如回调执行时），如果当前线程的SynchronizationContext为null，它会自动创建一个默认的System.Threading.SynchronizationContext实例并关联到当前线程上。

这个创建过程只会触发一次——只有当第一次有代码需要使用同步上下文时才会发生。比如你的fooAsync()内部可能包含了异步回调、或者调用了依赖同步上下文的API，第一次执行这些逻辑时，.NET会自动为当前线程设置这个默认上下文。而线程池线程通常会被长期复用，所以后续这个线程再被调度时，SynchronizationContext.Current就会保持这个已创建的实例。

为什么这不是内存泄漏？ #

默认的System.Threading.SynchronizationContext是一个轻量级对象，它不会持有任何会导致内存泄漏的强引用。它只是线程池线程的一个关联属性，线程池线程本身的生命周期由CLR管理，当线程被回收时，这个上下文也会被释放。所以这种状态变化完全符合线程池的设计逻辑，不属于内存泄漏。

对你的代码的改进建议 #

依赖SynchronizationContext.Current == null来决定是否阻塞线程是不稳定的，因为上下文状态可能在运行过程中被改变。推荐两种更可靠的做法：

1. 直接使用GetAwaiter().GetResult()替代Wait()：

   fooAsync().GetAwaiter().GetResult();
   

   它不仅能避免Wait()可能带来的死锁风险（虽然在无上下文环境中风险较低），还会直接抛出原始异常，而不是包装成AggregateException，更便于调试。
2. 显式清除上下文后执行异步操作：
   如果必须确保在无上下文环境中运行fooAsync()，可以临时清除当前线程的同步上下文：

   var originalContext = SynchronizationContext.Current;
   try
   {
       SynchronizationContext.SetSynchronizationContext(null);
       fooAsync().Wait(); // 或者用GetAwaiter().GetResult()
   }
   finally
   {
       SynchronizationContext.SetSynchronizationContext(originalContext);
   }
   

   这种方式可以强制让异步操作在无上下文的环境中执行，避免后续线程被关联默认上下文。

另外，如果你的Worker Role使用的是较新的模型，建议直接使用异步入口点，完全避免阻塞线程，这才是异步编程的最佳实践。

内容的提问来源于stack exchange，提问作者Eric P