async await в C#: Task, Task<T>, WhenAll и частые ловушки

Большинство медленных операций в программе это ожидания: пока веб-сервер ответит, база данных вернёт строки, файл прочитается. async и await позволяют методу приостановиться на время такого ожидания, не держа поток в заложниках, а затем продолжить с того же места. Код при этом по-прежнему читается сверху вниз, как обычный.

Первый асинхронный метод

Метод async возвращает Task (без результата) или Task<T> (результат типа T). Внутри него await ожидает другую задачу и отдаёт её результат.

using System;
using System.Threading.Tasks;

class Program
{
    static async Task<decimal> GetPriceAsync(string product)
    {
        await Task.Delay(200);          // stands in for a network call
        return product == "tea" ? 2.50m : 4.00m;
    }

    static async Task RunAsync()
    {
        decimal tea = await GetPriceAsync("tea");
        decimal cake = await GetPriceAsync("cake");
        Console.WriteLine("Tea " + tea + ", cake " + cake + ", total " + (tea + cake));
    }

    static void Main()
    {
        RunAsync().GetAwaiter().GetResult();
    }
}

Вывод:

Tea 2.50, cake 4.00, total 6.50

GetPriceAsync пишет return 2.50m, а компилятор оборачивает это в Task<decimal>, который возвращает метод. await снова его распаковывает. Task.Delay это асинхронная версия Thread.Sleep: он завершается по истечении времени, не блокируя поток в промежутке.

Начиная с C# 7.1 сам Main может быть асинхронным, и именно так эту программу написали бы в современном .NET:

static async Task Main()
{
    decimal tea = await GetPriceAsync("tea");
    Console.WriteLine(tea);
}

Примеры на этой странице, которые можно запустить, вызывают асинхронный метод RunAsync из обычного Main через .GetAwaiter().GetResult(), и именно это генерирует компилятор для асинхронного Main. В консольном приложении это безопасно; почему тот же вызов опасен в коде интерфейса, объясняет раздел о взаимоблокировках.

Что происходит на await

Асинхронный метод выполняется синхронно до первого await на незавершённой задаче. В этот момент он возвращает вызывающему Task, а остаток метода становится продолжением, которое выполнится, когда ожидаемая задача завершится.

using System;
using System.Threading.Tasks;

class Program
{
    static async Task DownloadAsync()
    {
        Console.WriteLine("  Download: starting");
        await Task.Delay(300);
        Console.WriteLine("  Download: finished");
    }

    static async Task RunAsync()
    {
        Console.WriteLine("Calling DownloadAsync");
        Task download = DownloadAsync();          // runs until its first await
        Console.WriteLine("DownloadAsync returned a task; doing other work");
        await download;                           // now wait for it
        Console.WriteLine("Download awaited");
    }

    static void Main()
    {
        RunAsync().GetAwaiter().GetResult();
    }
}

Вывод:

Calling DownloadAsync
  Download: starting
DownloadAsync returned a task; doing other work
  Download: finished
Download awaited

«Download: starting» печатается до возврата из DownloadAsync, потому что всё до первого await выполняется в потоке вызывающего. Затем метод отдаёт незавершённую задачу, вызывающий продолжает работу, а «Download: finished» появляется, только когда задержка закончится. Вызов асинхронного метода запускает его; ожидание через await это способ дождаться результата.

async не создаёт поток. Пока метод приостановлен, его вообще не ждёт ни один поток, поэтому сервер может держать тысячи запросов в ожидании базы данных всего с несколькими потоками. Для работы, нагружающей процессор, которую нужно выполнить в другом потоке, используйте Task.Run, описанный на странице задачи.

Одновременный запуск операций через Task.WhenAll

Ожидание вызовов один за другим последовательно: каждый начинается только после завершения предыдущего. Когда операции не зависят друг от друга, запустите их все, а затем ожидайте вместе через Task.WhenAll:

using System;
using System.Diagnostics;
using System.Threading.Tasks;

class Program
{
    static async Task<int> FetchStockAsync(string item, int ms)
    {
        await Task.Delay(ms);   // simulated request
        return item.Length * 10;
    }

    static async Task RunAsync()
    {
        var sw = Stopwatch.StartNew();
        int a = await FetchStockAsync("apples", 300);
        int b = await FetchStockAsync("pears", 300);
        int c = await FetchStockAsync("plums", 300);
        Console.WriteLine("Sequential: " + (a + b + c) + " units in ~" + sw.ElapsedMilliseconds / 100 * 100 + " ms");

        sw.Restart();
        Task<int> ta = FetchStockAsync("apples", 300);   // all three start now
        Task<int> tb = FetchStockAsync("pears", 300);
        Task<int> tc = FetchStockAsync("plums", 300);
        int[] results = await Task.WhenAll(ta, tb, tc);
        Console.WriteLine("Concurrent: " + (results[0] + results[1] + results[2]) + " units in ~" + sw.ElapsedMilliseconds / 100 * 100 + " ms");
    }

    static void Main()
    {
        RunAsync().GetAwaiter().GetResult();
    }
}

Пример вывода:

Sequential: 160 units in ~900 ms
Concurrent: 160 units in ~300 ms

Последовательная версия занимает сумму трёх ожиданий, одновременная примерно столько же, сколько самое долгое. Task.WhenAll возвращает результаты в том же порядке, что и переданные задачи, независимо от того, какая завершилась первой. Он работает и со списком, и это обычная форма для «получить каждый элемент»: await Task.WhenAll(ids.Select(id => FetchAsync(id))).

Task.WhenAny это парный метод, который завершается, как только завершилась первая задача; он полезен для тайм-аутов и сценария «побеждает первый ответ».

Исключения в асинхронном коде

Исключение, выброшенное внутри асинхронного метода, сохраняется в возвращённой задаче и выбрасывается повторно, когда задачу ожидают, поэтому обычный try/catch вокруг await работает:

using System;
using System.Threading.Tasks;

class Program
{
    static async Task<string> LoadProfileAsync(int userId)
    {
        await Task.Delay(50);
        if (userId <= 0) throw new ArgumentOutOfRangeException(nameof(userId));
        return "profile " + userId;
    }

    static async Task RunAsync()
    {
        Task<string> task = LoadProfileAsync(-1);   // no exception yet
        Console.WriteLine("Task created, completed yet: " + task.IsCompleted);

        try
        {
            await task;                              // rethrown here
        }
        catch (ArgumentOutOfRangeException e)
        {
            Console.WriteLine("Caught " + e.GetType().Name + " for " + e.ParamName);
        }

        Task<string> ok = LoadProfileAsync(7);
        Task<string> bad = LoadProfileAsync(0);
        Task<string[]> all = Task.WhenAll(ok, bad);
        try
        {
            await all;
        }
        catch (ArgumentOutOfRangeException)
        {
            Console.WriteLine("WhenAll rethrew the first failure");
            Console.WriteLine("All failures: " + all.Exception.InnerExceptions.Count);
            Console.WriteLine("The other task still succeeded: " + ok.Result);
        }
    }

    static void Main()
    {
        RunAsync().GetAwaiter().GetResult();
    }
}

Вывод:

Task created, completed yet: False
Caught ArgumentOutOfRangeException for userId
WhenAll rethrew the first failure
All failures: 1
The other task still succeeded: profile 7

Вызов LoadProfileAsync(-1) не выбросил исключение: оно хранится в задаче, пока её кто-нибудь не начнёт ожидать. Задача, которую никто никогда не ожидает, полностью скрывает своё исключение, и это ещё одна причина всегда ожидать то, что вы запустили. С WhenAll оператор await выбрасывает первое исключение, а свойство Exception объединённой задачи (AggregateException) хранит их все. Чтение ok.Result там нормально, потому что ok уже завершилась.

async void: только для обработчиков событий

Асинхронный метод может также возвращать void. Избегайте этого везде, кроме обработчиков событий:

// Bad: the caller cannot await it or catch its exceptions.
static async void SaveAsync(Order order)
{
    await db.InsertAsync(order);   // if this throws, the process may crash
}

// Good: return Task, so callers can await and handle errors.
static async Task SaveAsync(Order order)
{
    await db.InsertAsync(order);
}

// Acceptable: an event handler must return void.
private async void SaveButton_Click(object sender, EventArgs e)
{
    try { await SaveAsync(currentOrder); }
    catch (Exception ex) { ShowError(ex); }
}

С async void нет задачи, которую можно ожидать, поэтому вызывающий идёт дальше до завершения работы, а исключение, выброшенное внутри, выбрасывается прямо в контексте синхронизации (или в пуле потоков), где его не достанет ни один try/catch вызывающего. В консольном или серверном приложении это обычно завершает процесс. Внутри асинхронного обработчика событий async void перехватывайте всё сами.

Родственная ошибка это вызов асинхронного метода без await. Компилятор предупреждает (CS4014), а метод выполняется в фоне, и никто не наблюдает ни за его результатом, ни за его ошибками.

Взаимоблокировки из-за .Result и .Wait()

Блокировка на задаче через .Result или .Wait() это место, где асинхронный код ломается чаще всего. В приложении с контекстом синхронизации (WinForms, WPF, MAUI, классический ASP.NET) последовательность такая:

1. Поток интерфейса вызывает GetDataAsync().Result и блокируется в ожидании задачи.
2. Внутри GetDataAsync завершается await. По умолчанию его продолжение должно выполниться в том контексте, где он начался: в потоке интерфейса.
3. Поток интерфейса заблокирован на шаге 1, поэтому продолжение никогда не выполняется, поэтому задача никогда не завершается, поэтому шаг 1 никогда не заканчивается.

Приложение зависает без всякого исключения. У консольных приложений и ASP.NET Core такого контекста нет, поэтому тот же код работает в тестовой программе и зависает в настольном приложении. Исправления:

• Используйте await на всём пути вверх по цепочке вызовов вместо блокировки («async до самого верха»). Обработчики событий для этого могут быть async void.
• В коде библиотек, которому не нужно возвращаться в контекст вызывающего, пишите await SomethingAsync().ConfigureAwait(false);. Тогда продолжение выполняется в пуле потоков, а не в захваченном контексте, и библиотека пропускает ненужное переключение потока. Оно защищает блокирующего вызывающего, только если так делает каждый await в цепочке, поэтому считайте это хорошей гигиеной библиотек, а не исправлением .Result.

Коду приложений в ASP.NET Core ConfigureAwait(false) не нужен, поскольку возвращаться некуда.

Частые ошибки

• Ожидание независимых вызовов по одному. Запустите их, затем await Task.WhenAll(...).
• Методы async void. Возвращайте Task; оставьте async void для обработчиков событий.
• .Result и .Wait() в коде интерфейса или классического ASP.NET. Они вызывают взаимоблокировку; используйте await.
• Забытый await. Работа выполняется без наблюдения, а её исключения пропадают.
• Обёртывание ввода-вывода в Task.Run. Асинхронный API вроде File.ReadAllTextAsync или HttpClient.GetStringAsync уже освобождает поток; Task.Run лишь добавляет переход в пул потоков.
• Предположение, что async означает «выполняется в другом потоке». Оно означает «может приостановиться без блокировки». Для работы, нагружающей процессор, используйте Task.Run.