Hjemmeside » Coding » Forstå synkron og asynkron JavaScript - del 1

    Forstå synkron og asynkron JavaScript - del 1

    synkron og asynkron er forvirrende konsepter i JavaScript, spesielt for nybegynnere. To eller flere ting er synkron når de skje på samme tid (synkroniseres) og asynkron når de ikke gjør det (ikke synkronisert).

    Selv om disse definisjonene er enkle å ta inn, er det faktisk mer komplisert enn det ser ut. Vi må ta hensyn til hva er synkronisert akkurat, og hva er det ikke.

    Du vil nok kalle en normal Fungerer i JavaScript synkron, ikke sant? Og hvis det er noe som setTimeout () eller AJAX som du jobber med, vil du referere til det som asynkron, ja? Hva om jeg forteller deg det både er asynkron på en måte?

    For å forklare Hvorfor, Vi må vende oss til Mr. X for hjelp.

    Scenario 1 - Mr X prøver synkronitet

    Her er oppsettet:

    1. Mr X er noen som kan svare på tøffe spørsmål, og utføre enhver forespurt oppgave.
    2. Den eneste måten å kontakte ham på er via en telefonsamtale.
    3. Uansett spørsmål eller oppgave du fikk, for å spørre Mr Xs hjelp til å utføre det; du ringer til ham.
    4. Mr X gir deg svaret eller fullfører oppgaven med en gang, og lar deg vite det det er gjort.
    5. Du legger ned mottakeren og føler innhold og går ut for en film.

    Det du nettopp har utført var en synkron (frem og tilbake) kommunikasjon med Mr X. Han lyttet da du spurte ham ditt spørsmål, og du lyttet da han svarte det.

    Scenario 2 - Mr X er ikke fornøyd med synkronisering

    Siden Mr X er så effektiv, begynner han å motta mange flere samtaler. Så hva skjer når du ringer ham, men han er allerede opptatt snakker med noen andre? Du vil ikke kunne spørre ham ditt spørsmål - ikke før han er ledig til å motta samtalen din. Alt du vil høre er en travel tone.

    Så hva kan Mr X gjøre for å bekjempe dette?

    Istedenfor å ringe direkte:

    1. Mr X hyr en ny fyr, Mr M, og gir ham en telefonsvarer for innringerne å forlate meldinger.
    2. Mr Ms jobb er å send en melding fra telefonsvareren til Mr X når han vet at Mr X har fullført behandlingen av alle tidligere meldinger og allerede er gratis å ta en ny.
    3. Så nå når du ringer til ham, i stedet for å få en travel tone, får du en melding til Mr X da vent på at han ringer deg tilbake (ingen filmtid ennå).
    4. Når Mr. X er ferdig med alle de oppkalte meldingene han mottok før din, vil han se på problemet ditt, og ringer deg tilbake å gi deg et svar.

    Nå ligger spørsmålet: var handlingene så langt synkron eller asynkron?

    Det er blandet. Når du forlot meldingen, Mr X lyttet ikke til det, så den kommende kommunikasjonen var asynkron.

    Men da han svarte, du var der og lyttet, hvilken gjør returkommunikasjonen synkron.

    Jeg håper nå du har fått en bedre forståelse av hvordan synkronisitet oppfattes når det gjelder kommunikasjon. Tid til å ta med JavaScript.

    JavaScript - et asynkront programmeringsspråk

    Når noen merker JavaScript asynkron, hva de refererer til generelt, er hvordan du kan Legg igjen en beskjed for det, og ikke ring din samtale med en opptatt tone.

    Funksjonssamtalen er Aldri direkte i JavaScript, de er bokstavelig talt gjort via meldinger.

    JavaScript bruker a meldingskø hvor innkommende meldinger (eller hendelser) holdes. en event-sløyfe (en meldingsleverandør) sender sekvensielt disse meldingene til en anropsstabel hvor de tilsvarende funksjonene til meldingene er stablet som rammer (funksjonsargumenter og variabler) for utførelse.

    Anropsstakken holder rammen for den opprinnelige funksjonen som kalles, og eventuelle andre rammer for funksjoner som kalles via nestede samtaler på toppen av det .

    Når en melding slutter seg til køen, venter den til samtalestakken er tom for alle rammer fra forrige melding, og når det er, hendelsesløkken dequeues den forrige meldingen, og legger til tilhørende rammer for den aktuelle meldingen til anropsstakken.

    Meldingen venter igjen til anropsstakken blir tom for sine egne tilhørende rammer (det vil si at henrettelsene av alle de stablede funksjonene er over), da dekkes av.

    Vurder følgende kode:

     funksjon foo ()  funksjonslinje () foo ();  funksjon baz () bar ();  baz (); 

    Funksjonen som kjøres, er Bas () (i siste rad av kodebiten), for hvilken en melding er lagt til i køen, og når hendelse-løkken plukker den opp, kalles stakken begynner å stable rammer til Bas (), bar (), og foo () på de relevante utførelsesstedene.

    Når utførelsen av funksjonene er fullført en etter en, er rammene deres fjernet fra anropsstakken, mens meldingen er venter fortsatt i køen, før Bas () er poppet fra stakken.

    Husk at funksjonsanropene er Aldri direkte i JavaScript, de er ferdige via meldinger. Så når du hører noen sier at JavaScript selv er et asynkront programmeringsspråk, anta at de snakker om det innebygde “svare maskin”, og hvordan du er fri til å legge igjen meldinger.

    Men hva med de spesifikke asynkrone metoder?

    Så langt har jeg ikke rørt på APIer som setTimeout () og AJAX, det er de som er spesielt referert til som asynkron. Hvorfor det?

    Det er viktig å forstå hva som er synkron eller asynkron. JavaScript, med hjelp av hendelser og event-loop, kan øve asynkron behandling av meldinger, men det betyr ikke alt i JavaScript er asynkron.

    Husk, jeg fortalte deg at meldingen ikke forlot før samtalestakken var tom for tilhørende rammer, akkurat som du ikke forlot en film før du fikk svaret ditt - det er å være synkron, du venter der til oppgaven er fullført, og du får svaret.

    Venter er ikke ideell i alle scenarier. Hva om etter å ha forlatt en melding, i stedet for å vente, kan du gå for filmen? Hva om en funksjon kan trekke seg tilbake (tømme anropsstakken), og meldingen kan avkrysses selv før funksjonens oppgave er fullført? Hva om du kan ha kode utført asynkront?

    Dette er hvor APIer som setTimeout () og AJAX kommer inn på bildet, og hva de gjør er ... fortsett, jeg kan ikke forklare dette uten å gå tilbake til Mr X, som vi ser i den andre delen av denne artikkelen. Følg med.