WCF异步调用导致程序挂起？请求分析原因

我定义并实现了一个包含同步方法和异步方法的WCF契约：

[ServiceContract]
public interface IFooService
{
    [OperationContract]
    string GetFoo(int value);

    [OperationContract]
    Task<string> GetBarAsync();
}

public class FooService : IFooService
{
    public string GetFoo(int value)
    {
        return value.ToString();
    }

    public Task<string> GetBarAsync()
    {
        return Task.Run(() =>
        {
            Task.Delay(6000).Wait();
            return "done!";
        });
    }
}

客户端控制台程序代码如下：

class Program
{
    public static async Task Main(string[] args)
    {
        NetNamedPipeBinding binding = new NetNamedPipeBinding();
        var proxy = new ChannelFactory<IFooService>(binding, new EndpointAddress("net.pipe://localhost/Test")).CreateChannel();


        Console.WriteLine("GetFoo result: " + proxy.GetFoo(1));
        var tmp = await proxy.GetBarAsync();
        Console.WriteLine("GetBarAsync result: " + tmp);
        Console.WriteLine("GetFoo result: " + proxy.GetFoo(2));
        Console.ReadLine();
    }
}

程序输出了GetFoo result: 1，等待6秒后输出GetBarAsync result: done!，但之后就挂起，始终无法输出最后一行GetFoo result: 2。请问这是死锁导致的吗？还是WCF Channel不支持异步调用？

这是WCF通道线程关联引发的死锁，并非通道不支持异步调用。

核心原因 #

NetNamedPipeBinding（命名管道绑定）的通道默认采用单线程公寓（STA）模式，且WCF通道实例会绑定到发起调用的线程。当await proxy.GetBarAsync()执行完成后，后续代码会尝试回到原线程上下文继续执行，但此时原线程因通道的锁定机制被阻塞，导致最后一次GetFoo(2)的调用无法获取通道访问权限，最终程序挂起。

另外，服务端的GetBarAsync是假异步实现：用Task.Run包裹同步阻塞代码（Task.Delay(6000).Wait()）不仅没有发挥异步的优势，还可能加剧线程资源的消耗。

可行的解决办法 #

• 修改客户端await逻辑，避开线程上下文捕获
  在await时添加ConfigureAwait(false)，让后续代码不强制回到原线程上下文，从而绕开通道的线程绑定限制：

  var tmp = await proxy.GetBarAsync().ConfigureAwait(false);
  

• 将服务端异步方法改为真异步实现
  重构服务端的GetBarAsync，使用await替代同步阻塞的Wait()，实现真正的异步逻辑：

  public async Task<string> GetBarAsync()
  {
      await Task.Delay(6000);
      return "done!";
  }
  

  推荐将这两种方法结合使用，既能优化服务端性能，又能彻底避免客户端的死锁问题。

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