Asinchroninis programavimas leidžia atlikti daug išteklių reikalaujančias įvesties / išvesties operacijas, nebereikalaujant blokuoti pagrindinės ar vykdomosios programos gijos. Nors tai naudinga ir, atrodo, lengva įgyvendinti, ji turi daug sudėtingumo ir rizikos. Galima rizika, susijusi su asinchroniniu programavimu, ypač naudojant netinkamą asinchroninį programavimą, nesilaikant rekomenduojamos praktikos, yra aklavietės, proceso strigtys ir net lėtas veikimas. Jūs taip pat turėtumėte mokėti rašyti, derinti asinchroninį kodą.
Async metoduose venkite negaliojančio grąžinimo tipo
Metodas C # formoje yra asinchroninis metodas, naudojant metodo paraše esantį asinchroninį raktinį žodį. Async metodo viduje galite turėti vieną ar daugiau laukiamų raktinių žodžių. Laukimo raktinis žodis naudojamas sustabdymo taškui žymėti. C # asinchroninis metodas gali turėti bet kurį iš šių grąžinimo tipų: Užduotis, Užduotis ir negaliojantis. Raktinis žodis „laukti“ naudojamas asinchroniniame metode, siekiant informuoti kompiliatorių, kad metodas gali turėti sustabdymo ir atnaujinimo tašką.
Atkreipkite dėmesį, kad naudojant TPL, „TPL“ grąžinimo negaliojančio atitikmuo yra asinchroninė užduotis. Turėtumėte žinoti, kad async void yra ir turėtų būti naudojama tik asinchroniniams įvykiams. Jei naudosite jį bet kur kitur, susidursite su klaidomis. Kitaip tariant, nerekomenduojamas asinchroninis metodas, kurio grąžinimo tipas negalioja. nes asinchroniniai metodai, kurie grąžina negaliojančius, turi skirtingą semantiką, kai dirbate su savo programos išimtimis.
Kai išimtis įvyksta asinchroniniame metode, kurio grąžinimo tipas yra Užduotis arba Užduotis, išimties objektas saugomas objekto Užduotis viduje. Priešingai, jei turite asinchroninį metodą su grįžimo tipu negaliojančiu, nėra susietas užduoties objektas. Tokios išimtys keliamos „SynchronizationContext“, kuris buvo aktyvus tuo metu, kai buvo iškviestas asinchroninis metodas. Kitaip tariant, jūs negalite tvarkyti išimčių, iškeltų async void metodu, naudojant išimčių tvarkytuvus, įrašytus asinchroninio metodo viduje. Async metodus, kurių grįžimo tipas yra tuštumas, taip pat sunku išbandyti dėl šio klaidų tvarkymo semantikos skirtumo. Jūsų informacija yra „SynchronizationContext“ klasė sistemoje. Vardų srities išplėtimas reiškia .Net sinchronizavimo kontekstą ir padeda užduotį įtraukti į kitą kontekstą.
Tai iliustruoja šis kodų sąrašas. Turite du metodus, būtent „Test“ ir „TestAsync“, o pastarasis išmeta išimtį.
visuomenės klasė „AsyncDemo“
{
viešai negaliojantis testas ()
{
bandyti
{
TestAsync ();
}
sugavimas (ex išimtis)
{
Console.WriteLine (pvz., Žinutė);
}
}
privatus async negalioja TestAsync ()
{
mesti naują išimtį ("Tai yra klaidos pranešimas");
}
}
Štai kaip galite sukurti „AsyncDemo“ klasės egzempliorių ir pasinaudoti bandymo metodu.
static void Main (string [] args)
{
AsyncDemo obj = naujas AsyncDemo ();
obj.Testas ();
Pultas.Skaitykite ();
}
Bandymo metodas paskambina į „TestAsync“ metodą ir iškvietimas įvyniojamas į bandymo sugavimo bloką, kad būtų galima tvarkyti „TestAsync“ metodo išimtį. Tačiau išimtis, įmesta į „TestAsync“ metodą, niekada nebus užfiksuota, ty bus tvarkoma skambintojo metodo „Test“ viduje.
Venkite asinchroninio ir sinchroninio kodo maišymo
Niekada neturėtumėte turėti sinchroninio ir asinchroninio kodo derinio. Bloga programavimo praktika užblokuoti asinchroninį kodą skambinant į „Task.Wait“ arba „Task.Result“. Aš rekomenduočiau naudoti asinchroninį kodą nuo galo iki galo - tai saugiausias būdas išvengti klaidų.
Galite išvengti strigčių naudodami.ConfigureAwait (ContinOnCapturedContext: false) bet kada paskambinę laukti. Jei to nenaudosite, asinchroninis metodas užblokuos tą vietą, kai buvo iškviestas laukimas. Šiuo atveju jūs tik informuojate padavėją, kad jis neužfiksuotų dabartinio konteksto. Sakyčiau, kad tai yra gera praktika naudoti .ConfigureAwait (false), nebent turite konkrečių priežasčių jo nenaudoti.
Aptarčiau daugiau apie asinchroninį programavimą savo būsimuose tinklaraščio įrašuose čia. Norėdami gauti daugiau informacijos apie geriausią asinchroninio programavimo patirtį, skaitykite puikų Stepheno Cleary straipsnį MSDN.
