Hemsida » Kodning » Förstå synkron och asynkron JavaScript - Del 1

    Förstå synkron och asynkron JavaScript - Del 1

    Synkron och asynkron är förvirrande begrepp i JavaScript, speciellt för nybörjare. Två eller fler saker är synkron när de hända samtidigt (synkroniserad) och asynkron när de inte gör det (inte synkroniserad).

    Även om dessa definitioner är lätta att ta in, är det faktiskt mer komplicerat än det ser ut. Vi måste ta hänsyn till vad exakt är synkroniserad, och vad är det inte.

    Du skulle noga ringa en vanligt funktionen i JavaScript synkron, eller hur? Och om det är något liknande setTimeout () eller AJAX som du jobbar med, kommer du att referera till det som asynkron, ja? Vad händer om jag säger det till dig både är asynkrona på ett sätt?

    Förklara Varför, Vi måste vända oss till Mr X för hjälp.

    Scenario 1 - Mr X försöker synkronisera

    Här är inställningen:

    1. Mr X är någon som kan svara på svåra frågor och utföra eventuell uppmanad uppgift.
    2. Det enda sättet att kontakta honom är genom ett telefonsamtal.
    3. Oavsett vilken fråga eller uppgift du har, för att fråga Mr Xs hjälp att utföra det. du ringer honom.
    4. Mr X ger dig svaret eller fullgör uppgiften direkt, och låter dig veta det är gjort.
    5. Du sätter ner mottagaren och känner innehåll och går ut för en film.

    Det du just har utfört var en synkron (fram och tillbaka) kommunikation med Mr X. Han lyssnade när du frågade honom din fråga, och du lyssnade när han svarade på det.

    Scenario 2 - Mr X är inte nöjd med synkronisitet

    Eftersom Mr X är så effektiv börjar han ta emot flera fler samtal. Så vad händer när du ringer honom men han är redan upptagen pratar med någon annan? Du kommer inte att kunna fråga honom din fråga - förrän han är fri att få ditt samtal. Allt du hör är en upptagen ton.

    Så vad kan Mr X göra för att bekämpa detta?

    I stället för att ringa direkt:

    1. Mr X hyr en ny kille, herr M och ger honom en telefonsvarare för de som ringer att lämna meddelanden.
    2. Herr Ms jobb är att vidarebefordra ett meddelande från telefonsvararen till Mr X när han vet att X har slutfört behandlingen av alla tidigare meddelanden och redan är fri att ta en ny.
    3. Så nu när du ringer till honom, istället för att få en upptagen ton får du lämna ett meddelande till herr X då vänta på att han ringer dig tillbaka (ingen filmtid ännu).
    4. När Mr X är klar med alla de uppkönade meddelanden som han mottog före din, kommer han att undersöka problemet och ringer tillbaka för att ge dig ett svar.

    Nu ligger frågan: var handlingarna hittills synkron eller asynkron?

    Det är blandat. När du lämnade ditt meddelande, Mr X lyssnade inte på det, så den kommande kommunikationen var asynkron.

    Men när han svarade, du var där och lyssnade, som gör returkommunikationen synkron.

    Jag hoppas nu att du har fått en bättre förståelse för hur synkronicitet uppfattas när det gäller kommunikation. Det är dags att ta med JavaScript.

    JavaScript - ett asynkront programmeringsspråk

    När någon etiketterar JavaScript asynkron är vad de hänvisar till i allmänhet hur du kan lämna ett meddelande för det och Håll inte ditt samtal blockerat med en upptagen ton.

    Funktionssamtal är Direkt aldrig i JavaScript, de görs bokstavligen via meddelanden.

    JavaScript använder a meddelandekö där inkommande meddelanden (eller händelser) hålls. En händelse-loop (en meddelandesändare) skickar dessa meddelanden i följd till en samtalstack där motsvarande funktioner i meddelandena är staplade som ramar (funktionskänningar och variabler) för utförande.

    Samtalstacken håller ramen för den inledande funktionen som heter, och alla andra ramar för funktioner som kallas via nestade samtal ovanpå det .

    När ett meddelande går i kön väntar det tills samtalstapeln är tom för alla ramar från föregående meddelande, och när det är händelse-loop avkänner föregående meddelande, och lägger till motsvarande ramar för det aktuella meddelandet till samtalstapeln.

    Meddelandet väntar igen tills samtalstapeln blir tom för sina egna motsvarande ramar (dvs utförandet av alla de staplade funktionerna är över), avkodas sedan.

    Tänk på följande kod:

     funktion foo ()  funktionsfältet () foo ();  funktion baz () bar ();  baz (); 

    Funktionen som körs är baz () (i sista raden i kodbiten), för vilken ett meddelande läggs till i köen, och när händelsesslangen plockar upp den, ringer samtalstacken börjar stapla ramar för baz (), bar(), och foo () vid de relevanta genomförandepunkterna.

    När utförandet av funktionerna är fullständigt en efter en, är deras ramar borttagen från samtalstacken, medan meddelandet är väntar fortfarande i köen, fram tills baz () poppas från stapeln.

    Kom ihåg att funktionssamtal är Direkt aldrig i JavaScript, de är klara via meddelanden. Så när du hör någon säger att JavaScript själv är ett asynkront programmeringsspråk, antar att de pratar om sin inbyggda “telefonsvarare”, och hur du är fri att lämna meddelanden.

    Men hur är det med de specifika asynkrona metoderna?

    Hittills har jag inte berört API: er som setTimeout () och AJAX, det är de som är specifikt kallad asynkron. Varför är det så?

    Det är viktigt att förstå vad som exakt är synkron eller asynkron. JavaScript, med hjälp av händelser och evenemangsling, kan träna asynkron behandling av meddelanden, men det betyder inte allt i JavaScript är asynkron.

    Kom ihåg att jag sa att meddelandet lämnade inte förrän samtalstacken var tom för sina motsvarande ramar, precis som att du inte lämnade en film tills du fick ditt svar - det är det vara synkron, du väntar där tills uppgiften är klar, och du får svaret.

    Väntar är inte idealisk i alla scenarier. Vad händer om du efter att ha lämnat ett meddelande istället för att vänta kan du lämna filmen? Vad händer om en funktion kan gå i pension (tömning av samtalstacken), och meddelandet kan avkodas redan innan funktionen är avslutad? Vad händer om du kan ha kod exekverad asynkront?

    Det här är API: er som setTimeout () och AJAX kommer in i bilden, och vad de gör är ... håll på, jag kan inte förklara detta utan att gå tillbaka till Mr X, som vi kommer se i den andra delen av den här artikeln. Håll dig igång.