Forståelse af synkron og asynkron JavaScript - Del 1

Synkron og asynkron er forvirrende begreber i JavaScript, især for begyndere. To eller flere ting er synkron når de ske på samme tid (synkroniseres) og asynkron, når de ikke gør det (ikke synkroniseret).

Selv om disse definitioner er nemme at tage i, er det faktisk mere kompliceret, end det ser ud. Vi skal tage højde for Hvad er der i synkronisering, og hvad er det ikke.

Du vil nok kalde en normal funktion i JavaScript synkroniseret, ikke? Og hvis det er noget lignende setTimeout () eller AJAX, som du arbejder med, vil du referere til det som asynkron, ja? Hvad hvis jeg fortæller dig det begge er asynkrone på en måde?

At forklare hvorfor, vi skal henvende os til hr. x for hjælp.

Scenario 1 - Mr X forsøger synkronicitet

Her er opsætningen:

1. Hr. X er en person, der kan besvare hårde spørgsmål og udføre enhver anmodet opgave.
2. Den eneste måde at kontakte ham på er gennem et telefonopkald.
3. Uanset hvilket spørgsmål eller opgave du har, for at spørge hr. Xs hjælp til at udføre det; du ringer til ham.
4. Hr. X giver dig svaret eller fuldfører opgaven med det samme, og lader dig vide Det er gjort.
5. Du sætter modtageren i stand til at føle indhold og gå ud til en film.

Hvad du lige har udført var en synkron (frem og tilbage) kommunikation med hr. x. han lyttede som du spurgte ham dit spørgsmål, og du lyttede, da han svarede det.

Scenario 2 - Hr. X er ikke tilfreds med synchronicitet

Da hr. X er så effektiv, begynder han at modtage mange flere opkald. Så hvad sker der, når du kalder ham men han er allerede optaget taler til en anden? Du vil ikke være i stand til at spørge ham dit spørgsmål - ikke før han er fri til at modtage dit opkald. Alt du vil høre er en travl tone.

Så hvad kan hr. X gøre for at bekæmpe dette?

I stedet for at ringe direkte:

1. Hr. X ansætter en ny fyr, hr. M, og giver ham en telefonsvarer til opkaldere at forlade meddelelser.
2. Hr. M's job er at videresende en besked fra telefonsvareren til hr. X, når han ved, at hr. X helt er færdig med at behandle alle tidligere meddelelser og allerede er fri til at tage en ny.
3. Så nu når du ringer til ham, i stedet for at få en travl tone, får du en besked til hr. X, da vent på, at han ringer til dig igen (ingen film tid endnu).
4. Når hr. X er færdig med alle de opkøbte meddelelser, han modtog før din, vil han undersøge dit problem og ringer tilbage at give dig et svar.

Nu ligger spørgsmålet: var handlingerne hidtil synkron eller asynkron?

Det er blandet. Når du forlod din besked, Hr. X lyttede ikke til det, så den kommende kommunikation var asynkron.

Men da han svarede, du var der lytter, hvilken gør returkommunikationen synkron.

Jeg håber nu, at du har opnået en bedre forståelse af, hvordan synkronitet opfattes i form af kommunikation. Tid til at medbringe JavaScript.

JavaScript - et asynkront programmeringssprog

Når en person mærker JavaScript asynkront, er det generelt, hvordan man kan henvise til det Læg en besked for det og ikke have dit opkald blokeret med en travl tone.

Funktionsopkaldene er aldrig direkte i JavaScript, de er bogstaveligt talt gjort via meddelelser.

JavaScript bruger a meddelelseskø hvor indkommende meddelelser (eller begivenheder) holdes. en event-løkke (en meddelelseskort) sender sekventielt disse meddelelser til en call stack hvor de tilsvarende funktioner i meddelelserne er stablet som rammer (funktionskendelser og variabler) til udførelse.

Opkaldsstakken indeholder rammen for den indledende funktion, der kaldes, og eventuelle andre rammer for funktioner, der kaldes via indlejrede opkald Oven på det .

Når en meddelelse slutter sig til køen, venter den, indtil opkaldsstakken er tom for alle billeder fra den foregående meddelelse, og når det er, begivenhedsløkken dequeues den foregående meddelelse, og tilføjer de tilsvarende rammer af den aktuelle besked til opkaldsstakken.

Meddelelsen venter igen, indtil opkaldsstakken bliver tom for sine egne tilsvarende rammer (det vil sige at henrettelserne af alle de stablede funktioner er overstået), afkodes derefter.

Overvej følgende kode:

 funktion foo ()  funktionslinje () foo ();  funktion baz () bar ();  baz (); 

Funktionen der køres er baz () (i den sidste række af kodestykket), for hvilket en meddelelse er tilføjet til køen, og når event-loop løfter det op, opkald stakken begynder at stable rammer til baz (), bar(), og foo () på de relevante udførelsessteder.

Når udførelsen af ​​funktionerne er færdig en efter en, er deres rammer fjernet fra opkaldsstakken, mens meddelelsen er venter stadig i køen, så længe baz () poppes fra stakken.

Husk, at funktionsopkaldene er aldrig direkte i JavaScript, de er færdige via meddelelser. Så når du hører nogen siger, at JavaScript selv er et asynkront programmeringssprog, formoder, at de taler om det indbyggede “telefonsvarer”, og hvordan du er fri til at forlade beskeder.

Men hvad med de specifikke asynkrone metoder?

Indtil videre har jeg ikke rørt på API'er som f.eks setTimeout () og AJAX, det er dem der er specifikt omtalt som asynkron. Hvorfor det?

Det er vigtigt at forstå, hvad der er synkron eller asynkron. JavaScript kan med hjælp af arrangementer og arrangementsløbet praktisere asynkron behandling af meddelelser, men det betyder ikke alt i JavaScript er asynkron.

Husk, jeg fortalte dig, at meddelelsen ikke gik, før opkaldsstakken var tom for de tilsvarende rammer, ligesom du ikke forlod en film, før du fik dit svar - det er det være synkron, du venter der indtil opgaven er færdig, og du får svaret.

Venter er ikke ideel i alle scenarier. Hvad hvis du efterlade en besked, i stedet for at vente, kan du forlade filmen? Hvad hvis en funktion kan gå i pension (tømning af opkaldsstakken), og dens besked kan afkodes, før funktionens opgave er færdig? Hvad hvis du kan have kode udført asynkront?

Det er her API'er som setTimeout () og AJAX kommer ind i billedet, og hvad de gør er ... vent, jeg kan ikke forklare dette uden at gå tilbage til hr. X, som vi får se i anden del af denne artikel. Bliv hængende.