为什么这个 xunit 测试死锁（在单 CPU 虚拟机上）？

Question

在单 CPU 虚拟机 (Ubuntu 18.4) 上运行以下测试

using System;
using System.Threading;
using System.Threading.Tasks;
using Xunit;

public class AsyncStuffTest
{
    [Fact]
    public void AsyncTest()
    {
        SomethingAsync().Wait();
    }

    private static async Task SomethingAsync()
    {
        Console.WriteLine("before async loop...");
        await Task.Factory.StartNew(() => {
                                        for (int i = 0; i < 10; i++)
                                        {
                                            Console.WriteLine("in async loop...");
                                            Thread.Sleep(500);     
                                        }
                                    });
        Console.WriteLine("after async loop...");
    }
}

结果如下：

Build started, please wait...
Build completed.

Test run for /home/agent/fancypants/bin/Debug/netcoreapp2.1/fancypants.dll(.NETCoreApp,Version=v2.1)
Microsoft (R) Test Execution Command Line Tool Version 15.7.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
before async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...

该过程似乎陷入僵局，永远无法达到预期的输出

after async loop...

在我的开发机器上运行一切正常。

注意：我知道 xunit 中异步测试的可能性。这或多或少是一个兴趣问题。特别是因为这个问题只影响 xunit，所以控制台应用程序正常终止：

~/fancypants2$ dotnet run
before async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
in async loop...
after async loop...
~/fancypants2$

更新： 阅读有关 xunit 中异步相关的一些最新修复，因此我使用 2.4.0-beta.2.build4010 尝试了此操作，但没有任何变化。

Answer 1

经过两天的绞尽脑汁

SynchronizationContext

（基本上，无需过多讨论“UI线程”的最佳信息可以在这里找到：https://blogs.msdn.microsoft.com/pfxteam/2012/01/ 20/await-synchronizationcontext-and-console-apps/）我明白发生了什么。

控制台应用程序不提供任何

SynchronizationContext

，因此CLR会将任务卸载到线程池上的线程。无论机器有什么 CPU，都有足够的可用线程。一切正常。

xUnit 确实提供了

Xunit.Sdk.MaxConcurrencySyncContext

来主动管理正在运行的线程数量。最大并发级别默认为您拥有的逻辑 CPU 数量，但是，它可以配置。运行测试的线程已经超出了此限制，因此任务完成被阻塞。

所有这一切都是为了重现一个更复杂的 ASP.NET Core Web 应用程序的问题，该应用程序在提到的单 CPU 构建代理上表现得很奇怪。集成测试使用集合范围的共享固定装置来启动

TestServer

public class ServiceHostFixture : IAsyncLifetime
{
    public async Task InitializeAsync()
    {
        IWebHostBuilder host = new WebHostBuilder()
                    .UseEnvironment("Production")
                    .UseStartup<Startup>();

        Server = new TestServer(host);
    }

    public async Task DisposeAsync()
    {
        Server.Dispose();
    }
}

虽然

Startup.Configure(IApplicationBuilder app)

中有一个有趣的地方：

app.ApplicationServices
    .GetRequiredService<IApplicationLifetime>()
    .ApplicationStarted
    .Register(async () => {
                    try
                    {
                        // it blocks here in xunit
                        await EnsureSomeBasicStuffExistenceInTheDatabaseAsync();
                    }
                    catch (Exception ex)
                    {
                        Logger.Fatal(ex, "Application could not be started");
                    }
                });

在我的（8 个逻辑 CPU）机器上，它工作正常，在单 CPU Web 主机上工作正常，但 xUnit 在单 CPU 上死锁。如果你仔细阅读

CancellationToken

的文档，你会发现

ApplicationStarted

到底是什么：

当前的

System.Threading.ExecutionContext

（如果存在）将与委托一起被捕获，并在执行时使用。

将此与 ASP.NET Core 和 xUnit 之间的差异结合起来就可以揭示问题。我所做的是以下解决方法：

app.ApplicationServices
    .GetRequiredService<IApplicationLifetime>()
    .ApplicationStarted
    .Register(async () => {
                    try
                    {
                        if (SynchronizationContext.Current == null)
                        {
                            // normal ASP.Net Core environment does not have a synchronization context, 
                            // no problem with await here, it will be executed on the thread pool
                            await EnsureSomeBasicStuffExistenceInTheDatabaseAsync;
                        }
                        else
                        {
                            // xunit uses it's own SynchronizationContext that allows a maximum thread count
                            // equal to the logical cpu count (that is 1 on our single cpu build agents). So
                            // when we're trying to await something here, the task get's scheduled to xunit's 
                            // synchronization context, which is already at it's limit running the test thread
                            // so we end up in a deadlock here.
                            // solution is to run the await explicitly on the thread pool by using Task.Run
                            Task.Run(() => EnsureSomeBasicStuffExistenceInTheDatabaseAsync()).Wait();
                        }
                    }
                    catch (Exception ex)
                    {
                        Logger.Fatal(ex, "Application could not be started");
                    }
                });

编辑 10/2023：在使用

WebApplicationFactory

和 xUnit 进行集成测试时，这可能会让您感到困惑。 有一个很好的解释。