Asynkron programmering lar deg utføre ressurskrevende I / O-operasjoner uten å måtte blokkere på hoved- eller kjøringstråden til applikasjonen. Selv om det er gunstig og tilsynelatende enkelt å implementere, kommer det med mye kompleksitet og risiko. De potensielle risikoene forbundet med asynkronisering, spesielt ved bruk av asynkron programmering på feil måte ved ikke å følge de anbefalte fremgangsmåtene, inkluderer fastlåsning, prosesskrasj og til og med langsom ytelse. Du bør også være dyktig i å skrive, feilsøke async-kode.
Unngå å ha ugyldig returtype i asynkroniseringsmetoder
En metode i C # er laget til en asynkron metode ved hjelp av async-nøkkelordet i metodesignaturen. Du kan ha et eller flere nøkkelord i en asynkroniseringsmetode. Det ventede nøkkelordet brukes til å betegne suspensjonspunktet. En asynkroniseringsmetode i C # kan ha en av disse returtypene: Oppgave, Oppgave og ugyldig. Nøkkelordet "venter" brukes i en asynkroniseringsmetode for å informere kompilatoren om at metoden kan ha et suspensjons- og gjenopptakspunkt.
Merk at når du bruker TPL, er ekvivalent med å returnere tomrom i TPL async Task. Du bør være oppmerksom på at asynkronisert tomrom er og bare skal brukes til asynkroniseringshendelser. Hvis du bruker den noe annet sted, vil du støte på feil. Med andre ord anbefales ikke en asynkroniseringsmetode som er ugyldig som returtype. fordi asynkroniseringsmetoder som returnerer ugyldige, har forskjellig semantikk når du arbeider med unntak i applikasjonen.
Når et unntak oppstår i en asynkroniseringsmetode som har en returtype Oppgave eller Oppgave, lagres unntaksobjektet inne i Oppgaveobjektet. Tvert imot, hvis du har en asynkroniseringsmetode med en returform av tomrom, er det ikke noe oppgaveobjekt tilknyttet. Slike unntak heves på SynchronizationContext som var aktiv da den asynkrone metoden ble kalt. Med andre ord, du kan ikke håndtere unntak som er hevet i en asynkron ugyldig metode ved hjelp av unntakshåndterere skrevet i den asynkrone metoden. Asynkroniseringsmetoder som har en returform av tomrom er også vanskelige å teste på grunn av denne forskjellen i feilhåndtering av semantikk. For din informasjon representerer SynchronizationContext-klassen i System.Trading-navneområdet en synkroniseringskontekst i .Net og hjelper deg med å stille en oppgave i kø til en annen kontekst.
Følgende kodeliste illustrerer dette. Du har to metoder, nemlig Test og TestAsync, og sistnevnte kaster et unntak.
offentlig klasse AsyncDemo
{
offentlig ugyldig test ()
{
prøve
{
TestAsync ();
}
fangst (Unntak eks)
{
Console.WriteLine (f.eks. Melding);
}
}
privat asynkronisering ugyldig TestAsync ()
{
kaste nytt unntak ("Dette er en feilmelding");
}
}
Slik kan du opprette en forekomst av AsyncDemo-klassen og påkalle testmetoden.
statisk tomrom Main (streng [] args)
{
AsyncDemo obj = ny AsyncDemo ();
obj.Test ();
Console.Read ();
}
Testmetoden ringer til TestAsync-metoden, og samtalen pakkes inn i en prøvefangstblokk med den hensikt å håndtere unntaket som kastes i TestAsync-metoden. Imidlertid vil unntaket som kastes i TestAsync-metoden, aldri bli fanget opp, dvs. håndteres inne i anropsmetoden Test.
Unngå å blande asynkron og synkron kode
Du bør aldri ha en blanding av synkron og asynkron kode. Det er en dårlig programmeringspraksis å blokkere asynkroniseringskode ved å ringe til Task.Wait eller Task.Result. Jeg vil anbefale å bruke async-kode fra ende til annen - det er den tryggeste måten å unngå at feil kryper inn.
Du kan unngå fastlåsning ved å bruke.ConfigureAwait (continueOnCapturedContext: false) når du ringer til å vente. Hvis du ikke bruker dette, vil asynkroniseringsmetoden blokkere på det punktet der ventet er blitt kalt. I dette tilfellet informerer du bare servitøren om ikke å fange den nåværende konteksten. Jeg vil si at det er en god praksis å bruke .ConfigureAwait (false) med mindre du har en spesifikk grunn til ikke å bruke den.
Jeg vil diskutere mer om asynkron programmering i mine fremtidige blogginnlegg her. For mer informasjon om beste praksis innen asynkron programmering, kan du se Stephen Clearys flotte artikkel på MSDN.
