Asynchronní programování umožňuje provádět I / O operace náročné na prostředky, aniž byste museli blokovat hlavní nebo prováděcí vlákno aplikace. Ačkoli je to výhodné a zdánlivě snadno implementovatelné, přináší to spoustu složitosti a rizik. Mezi potenciální rizika spojená s asynchronním programováním, zejména nesprávným používáním asynchronního programování nedodržováním doporučených postupů, patří zablokování, selhání procesu a dokonce i pomalý výkon. Měli byste také ovládat psaní a ladění asynchronního kódu.
Vyhněte se použití typu void return v asynchronních metodách
Metoda v C # je vytvořena jako asynchronní metoda pomocí klíčového slova async v podpisu metody. V asynchronní metodě můžete mít jedno nebo více klíčových slov. Klíčové slovo await se používá k označení bodu pozastavení. Asynchronní metoda v C # může mít některý z těchto návratových typů: Task, Task a void. Klíčové slovo "await" se používá v asynchronní metodě k informování kompilátoru o tom, že metoda může mít bod pozastavení a obnovení.
Všimněte si, že při použití TPL je ekvivalentem návratu void v TPL asynchronní úkol. Měli byste si uvědomit, že async void je a měl by být použit pouze pro asynchronní události. Pokud jej použijete kdekoli jinde, narazili byste na chyby. Jinými slovy, asynchronní metoda, která má jako návratový typ void, se nedoporučuje. protože asynchronní metody, které vracejí prázdno, mají při práci s výjimkami ve vaší aplikaci jinou sémantiku.
Když dojde k výjimce v asynchronní metodě, která má návratový typ Task nebo Task, objekt výjimky je uložen uvnitř Task objektu. Naopak, pokud máte asynchronní metodu s návratovým typem void, není přidružen žádný objekt Task. Takové výjimky jsou vyvolány na SynchronizationContext, který byl aktivní v době, kdy byla volána asynchronní metoda. Jinými slovy nemůžete zpracovat výjimky vyvolané v rámci metody async void pomocí obslužných rutin výjimek zapsaných uvnitř asynchronní metody. Asynchronní metody, které mají návratový typ prázdnoty, je také obtížné otestovat kvůli tomuto rozdílu v sémantice zpracování chyb. Pro vaši informaci představuje třída SynchronizationContext v oboru názvů System.Threading synchronizační kontext v .Net a pomůže vám zařadit úkol do jiného kontextu.
Následující příklad kódu to ilustruje. Máte dvě metody, jmenovitě Test a TestAsync a ta vyvolá výjimku.
veřejná třída AsyncDemo
{
test veřejné neplatnosti ()
{
Snaž se
{
TestAsync ();
}
úlovek (výjimka mimo)
{
Console.WriteLine (např. Zpráva);
}
}
private async void TestAsync ()
{
vyvolá novou výjimku („Toto je chybová zpráva“);
}
}
Tady je způsob, jak můžete vytvořit instanci třídy AsyncDemo třídy a vyvolat metodu Test.
static void Main (řetězec [] args)
{
AsyncDemo obj = new AsyncDemo ();
obj.Test ();
Console.Read ();
}
Testovací metoda provede volání TestAsync metody a volání je zabaleno uvnitř bloku try-catch se záměrem zpracovat výjimku vyvolanou uvnitř TestAsync metody. Výjimka vyvolaná uvnitř metody TestAsync však nikdy nebude zachycena, tj. Zpracována uvnitř metody volajícího Test.
Vyhněte se míchání asynchronního a synchronního kódu
Nikdy byste neměli mít kombinaci synchronního a asynchronního kódu. Blokovat asynchronní kód voláním na Task.Wait nebo Task.Result je špatný programovací postup. Doporučil bych použít asynchronní kód od začátku do konce - je to nejbezpečnější způsob, jak se vyhnout chybám při pronikání dovnitř.
Zablokování můžete zabránit použitím.ConfigureAwait (continueOnCapturedContext: false) kdykoli zavoláte a čekáte. Pokud toto nepoužíváte, asynchronní metoda by se zablokovala v místě, kde bylo voláno čekání. V tomto případě pouze informujete čekajícího, aby nezachytil aktuální kontext. Řekl bych, že je dobrým zvykem používat .ConfigureAwait (false), pokud nemáte konkrétní důvod jej nepoužívat.
Více o asynchronním programování bych diskutoval ve svých budoucích příspěvcích na blogu zde. Další informace o osvědčených postupech v asynchronním programování najdete ve skvělém článku Stephena Clearyho na webu MSDN.
