C# async await: Task, Task<T>, WhenAll und typische Fallen

Die meisten langsamen Operationen in einem Programm sind Wartezeiten: darauf, dass ein Webserver antwortet, eine Datenbank Zeilen liefert, eine Datei gelesen wird. Mit async und await kann eine Methode während einer solchen Wartezeit pausieren, ohne einen Thread festzuhalten, und dann dort weitermachen, wo sie aufgehört hat. Der Code liest sich trotzdem von oben nach unten wie gewöhnlicher Code.

Eine erste async-Methode

Eine async-Methode gibt Task (kein Ergebnis) oder Task<T> (ein Ergebnis vom Typ T) zurück. Darin wartet await auf einen anderen Task und gibt dir sein Ergebnis.

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();
    }
}

Ausgabe:

Tea 2.50, cake 4.00, total 6.50

GetPriceAsync sagt return 2.50m, und der Compiler verpackt das in den Task<decimal>, den die Methode zurückgibt. await packt ihn wieder aus. Task.Delay ist die async-Version von Thread.Sleep: Es ist nach Ablauf der Zeit fertig, ohne in der Zwischenzeit einen Thread zu blockieren.

Seit C# 7.1 kann Main selbst async sein, und so würdest du dieses Programm in modernem .NET schreiben:

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

Die ausführbaren Beispiele auf dieser Seite rufen eine async-Methode RunAsync aus einem normalen Main mit .GetAwaiter().GetResult() auf, was der Compiler für ein async Main erzeugt. In einer Konsolen-App ist das sicher; der Abschnitt zu Deadlocks erklärt, warum derselbe Aufruf in UI-Code gefährlich ist.

Was bei einem await passiert

Eine async-Methode läuft synchron bis zu ihrem ersten await auf einen unfertigen Task. An dieser Stelle gibt sie ihrem Aufrufer einen Task zurück, und der Rest der Methode wird zu einer Fortsetzung, die läuft, wenn der abgewartete Task fertig ist.

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();
    }
}

Ausgabe:

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

„Download: starting“ wird ausgegeben, bevor DownloadAsync zurückkehrt, weil alles bis zum ersten await auf dem Thread des Aufrufers läuft. Dann gibt die Methode einen unfertigen Task zurück, der Aufrufer macht weiter, und „Download: finished“ erscheint erst, wenn die Verzögerung vorbei ist. Eine async-Methode aufzurufen startet sie; sie abzuwarten ist der Weg, auf das Ergebnis zu warten.

async erzeugt keinen Thread. Während die Methode pausiert, wartet überhaupt kein Thread auf sie, deshalb kann ein Server tausende Anfragen auf eine Datenbank warten lassen und dabei nur eine Handvoll Threads verwenden. Für CPU-lastige Arbeit, die auf einem anderen Thread laufen soll, nimm Task.Run, behandelt unter Tasks.

Operationen gleichzeitig mit Task.WhenAll ausführen

Einen Aufruf nach dem anderen abzuwarten ist sequenziell: Jeder startet erst, nachdem der vorherige fertig ist. Wenn die Operationen nicht voneinander abhängen, starte sie alle und warte sie dann gemeinsam mit Task.WhenAll ab:

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();
    }
}

Beispielausgabe:

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

Die sequenzielle Version braucht die Summe der drei Wartezeiten, die nebenläufige ungefähr so lange wie die langsamste. Task.WhenAll gibt die Ergebnisse in derselben Reihenfolge wie die übergebenen Tasks zurück, egal welcher zuerst fertig war. Es funktioniert auch mit einer Liste, der üblichen Form für „hol jedes Element“: await Task.WhenAll(ids.Select(id => FetchAsync(id))).

Task.WhenAny ist das Gegenstück, das fertig ist, sobald der erste Task fertig ist, nützlich für Timeouts und „die erste Antwort gewinnt“.

Exceptions in async-Code

Eine in einer async-Methode geworfene Exception wird im zurückgegebenen Task gespeichert und erneut geworfen, wenn der Task abgewartet wird, ein gewöhnliches try/catch um das await funktioniert also:

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();
    }
}

Ausgabe:

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

Der Aufruf von LoadProfileAsync(-1) hat nicht geworfen: Die Exception lebt im Task, bis etwas ihn abwartet. Ein Task, den nie jemand abwartet, verbirgt seine Exception vollständig, ein weiterer Grund, immer abzuwarten, was du startest. Bei WhenAll wirft await die erste Exception erneut, während die Property Exception des kombinierten Tasks (eine AggregateException) alle enthält. ok.Result zu lesen ist dort in Ordnung, weil ok bereits fertig ist.

async void: nur für Event-Handler

Eine async-Methode kann auch void zurückgeben. Vermeide das überall außer bei Event-Handlern:

// 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); }
}

Bei async void gibt es keinen Task zum Abwarten, der Aufrufer macht also weiter, bevor die Arbeit erledigt ist, und eine darin geworfene Exception wird direkt im Synchronisationskontext (oder im Thread-Pool) ausgelöst, wo kein try/catch eines Aufrufers sie erreicht. In einer Konsolen- oder Server-App beendet das meist den Prozess. Fang in einem async void Event-Handler alles selbst ab.

Ein verwandter Fehler ist, eine async-Methode ohne await aufzurufen. Der Compiler warnt (CS4014), und die Methode läuft im Hintergrund, ohne dass jemand ihr Ergebnis oder ihre Fehler beobachtet.

Deadlocks durch .Result und .Wait()

Mit .Result oder .Wait() auf einen Task zu blockieren ist die Stelle, an der async-Code am häufigsten schiefgeht. In einer Anwendung mit Synchronisationskontext (WinForms, WPF, MAUI, klassisches ASP.NET) ist der Ablauf:

1. Der UI-Thread ruft GetDataAsync().Result auf und blockiert, während er auf den Task wartet.
2. In GetDataAsync ist ein await fertig. Standardmäßig muss seine Fortsetzung in dem Kontext laufen, in dem sie begonnen hat: dem UI-Thread.
3. Der UI-Thread ist in Schritt 1 blockiert, die Fortsetzung läuft also nie, der Task wird nie fertig, und Schritt 1 endet nie.

Die App friert ohne Exception ein. Konsolen-Apps und ASP.NET Core haben keinen solchen Kontext, deshalb funktioniert derselbe Code in einem Testprogramm und hängt in einer Desktop-App. Die Lösungen:

• Nimm await die ganze Aufrufkette hinauf, statt zu blockieren („async all the way“). Event-Handler können dafür async void sein.
• In Bibliothekscode, der nicht in den Kontext des Aufrufers zurückkehren muss, schreibe await SomethingAsync().ConfigureAwait(false);. Die Fortsetzung läuft dann im Thread-Pool statt im erfassten Kontext, und die Bibliothek spart sich einen unnötigen Threadwechsel. Einen blockierenden Aufrufer schützt das nur, wenn jedes await in der Kette dasselbe tut, betrachte es also als gute Praxis für Bibliotheken, nicht als Lösung für .Result.

Anwendungscode in ASP.NET Core braucht kein ConfigureAwait(false), weil es keinen Kontext gibt, in den er zurückkehren müsste.

Häufige Fehler

• Unabhängige Aufrufe einzeln abwarten. Starte sie, dann await Task.WhenAll(...).
• async void-Methoden. Gib Task zurück; behalte async void für Event-Handler.
• .Result und .Wait() in UI- oder klassischem ASP.NET-Code. Sie verursachen Deadlocks; warte stattdessen mit await.
• await vergessen. Die Arbeit läuft unbeobachtet, und ihre Exceptions verschwinden.
• I/O in Task.Run verpacken. Eine async-API wie File.ReadAllTextAsync oder HttpClient.GetStringAsync gibt den Thread bereits frei; Task.Run fügt nur einen Umweg über den Thread-Pool hinzu.
• Annehmen, dass async „läuft auf einem anderen Thread“ bedeutet. Es bedeutet „kann pausieren, ohne zu blockieren“. Nimm Task.Run für CPU-lastige Arbeit.