在 .NET 中使用 ConfigureAwait

Question

我在各个地方看过ConfigureAwait(包括SO问题)，以下是我的结论:

• 配置等待（true）：在运行wait之前在同一线程上运行其余代码。
• 配置等待（false）：在运行等待代码的同一线程上运行其余代码。
• 如果wait后面跟着访问UI的代码，则该任务应附加。配置等待（true）。否则，由于另一个线程访问UI元素，将发生InvalidoperationException。

我的问题是：

1. 我的结论正确吗？
2. 配置等待（false）什么时候提高性能，什么时候没有？
3. 如果为GUI应用程序编写，但接下来的行不访问UI元素。我应该使用配置等待（false）还是配置等待（true）？

Answer 1

在应用程序代码中使用 ConfigureAwait（false） 通常不会以任何有意义的方式提高应用程序的性能，因为通常您不会在应用程序代码中等待内部循环。例如，让我们考虑这样一种情况：你的应用有一个按钮，每次用户单击该按钮时都会启动一个异步操作，而异步操作包括一个 await。通过键入 22 个字符 。ConfigureAwait（false） 在此等待之后，您已经失去了生命中的可比时间，您希望从每分钟单击此按钮一次的10个用户中节省下来的时间，每天8小时，每个用户20年（总共约35，000，000次上下文切换=几秒的CPU处理时间）。

这在考虑您需要考虑是否可以安全地包含此配置的时间之前（取决于延续是否包含与UI相关的代码），每次必须维护/修改代码时重新确认之前的评估所需的时间，以及如果评估错误，您在调试时损失的时间。

另一方面，如果您的Button_Click处理程序包含如下代码：

private async void Button_Click(object sender, EventArgs e)
{
    var client = new WebClient();
    using var stream = await client.OpenReadTaskAsync("someUrl");
    var buffer = new byte[1024];
    while ((await stream.ReadAsync(buffer, 0, buffer.Length)) > 0)
    {
        //...
    }
}

...然后一定要花额外的时间来配置等待（假）ReadAsync任务。还要考虑通过将流读取部分移动到单独的异步方法来重构代码，这样您就可以安全地访问Button_Click处理程序中任何地方的UI元素，而不会被不属于应用程序这一层的技术问题分散注意力。

Answer 2

如果可用的工作线程不多，并且需要等待的线程经常处于忙碌状态，则< code > configurewait(false)可能会提高性能。

< code > configurea wait(false)在不需要返回到相同的SynchronizationContext(通常与thread链接)的任何地方都是推荐的，尤其是在内部等待某些东西的库中:https://medium . com/by nder-tech/c-why-you-should-use-configurea wait-false-in-your-library-code-d 7837 DCE 3d 7 f。

当您需要相同的上下文时，需要< code > configurewait(true)(这是默认值)，但在某些情况下也可能导致死锁。

考虑以下代码：

void Main()
{
    // creating a windows form attaches a synchronization context to the current thread
    new System.Windows.Forms.Form();
    var task = DoSth();
    Console.WriteLine(task.Result);
}

async Task<int> DoSth()
{
    await Task.Delay(1000);
    return 1;
}

在此示例中，由于未等待任务 DoSth，主 UI 线程被等待任务所阻塞。结果 - 同时 DoSth 被阻止，因为它希望在延迟后返回到 UI 线程。这将导致死锁，并且此代码永远不会执行到最后。正在添加 .在这种情况下，ConfigureAwait（false） 解决了这个问题。

Answer 3

要更直接地回答您的问题：

ConfigureAwait(true):在运行Await之前，在同一线程上运行代码的剩余部分。

不一定是同一个线程，而是同一个同步上下文。同步上下文可以决定如何运行代码。在UI应用程序中，它将是同一个线程。在ASP。NET中，它可能不是同一个线程，但您将有＜code＞HttpContext＜/code＞可用，就像之前一样。

配置等待（false）：在运行等待代码的同一线程上运行其余代码。

这是不正确的。配置等待（false）告诉它它不需要上下文，因此代码可以在任何地方运行。它可以是运行它的任何线程。

如果等待之后是访问UI的代码，则任务应附加。ConfigureAwait（true）。否则，由于另一个线程访问UI元素，将发生InvalidOperationException。

它“应该附加。配置等待（true）”是不正确的。配置等待（true）是默认值。因此，如果这是您想要的，则无需指定它。

返回同步上下文可能需要时间，因为它可能需要等待其他东西完成运行。事实上，这种情况很少发生，或者等待时间很短，你根本不会注意到。

您可以使用< code > configurewait(false)，但我建议您不要这样做，原因如下:

1. 我怀疑你会注意到任何性能改进。
2. 它可能会引入您可能意想不到的并行性。如果您使用配置等待（false），延续可以在任何线程上运行，因此如果您访问非线程安全的对象，您可能会遇到问题。有这些问题并不常见，但它可能会发生。
3. 您（或维护此代码的其他人）可以稍后添加与UI交互的代码，并且将抛出异常。希望配置等待（false）很容易被发现（它可能采用与抛出异常的方法不同的方法）并且您/他们知道它的作用。

我发现根本不使用配置Await（假）更容易（除了在库中）。用Stephen Toub（微软员工）在ConfigalAwait FAQ中的话来说：

编写应用程序时，通常需要默认行为（这就是为什么它是默认行为的原因）。

编辑:我写了一篇自己的关于这个话题的文章:。NET:不要使用configurewait(false)