Uruchom kilka linii z setTimeout i obietnicą, a kolejność wyników może Cię zaskoczyć. Pętla zdarzeń JavaScript wyjaśnia dlaczego. Jest to mechanizm, który pozwala językowi jednowątkowemu obsługiwać liczniki czasu, połączenia sieciowe i kliknięcia bez zawieszania się.

Kiedy to zrozumiesz, cała klasa mylących błędów zacznie mieć sens. Każdy przykład uruchomiliśmy w Node.js 24, a dane wyjściowe pochodzą z tego uruchomienia. Podstawowe zasady porządkowania obowiązują również w przeglądarkach i wskazujemy, czym różni się Node.js. Zyskasz na tym więcej, jeśli znasz już podstawy obietnic JavaScript.

Dlaczego istnieje pętla zdarzeń

JavaScript wykonuje kod w jednym głównym wątku, więc w danym momencie działa tylko jeden jego fragment. Gdyby po prostu czekała na żądanie sieciowe, strona zawieszałaby się do czasu otrzymania odpowiedzi.

Zatem JavaScript nie czeka. Wolna praca przekazywana jest środowisku hosta, czyli przeglądarce lub Node.js, która radzi sobie z nią w tle. Po zakończeniu tej pracy wywołanie zwrotne jest umieszczane w kolejce. Zadaniem pętli zdarzeń jest przenoszenie wywołań zwrotnych z kolejki na stos, gdy jest on wolny.

Pomyśl o szefie kuchni pracującym samotnie. Szef kuchni zamiast się na nie gapić, wkłada danie do piekarnika i ustawia minutnik. Kiedy zadzwoni minutnik, zadanie trafia na listę, a szef kuchni podejmuje się go po skończeniu tego, co aktualnie jest w zasięgu ręki.

Ruchome części

Zadania są czasami nazywane makrozadaniami. Ściśle mówiąc, może istnieć kilka źródeł zadań, a dokładne szczegóły różnią się w zależności od środowiska.

Zasady

1. Uruchamiaj cały kod synchroniczny, aż stos wywołań będzie pusty.
2. Uruchamiaj wszystkie mikrozadania, łącznie z nowymi dodanymi po drodze.
3. W przeglądarce wyrenderuj aktualizację, jeśli jest ona wymagana.
4. Weź jedno zadanie z kolejki i uruchom je.
5. Wróć do kroku 2.

Najważniejszy szczegół: wszystkie mikrozadania, a następnie jedno zadanie. Większość zagadek z pętlą zdarzeń rozwiązuje się, stosując tę ​​pojedynczą regułę.

Zobacz zamówienie

console.log("1 sync");
setTimeout(() => console.log("5 timeout"), 0);
Promise.resolve().then(() => console.log("3 promise"));
queueMicrotask(() => console.log("4 microtask"));
console.log("2 sync");

// 1 sync
// 2 sync
// 3 promise
// 4 microtask
// 5 timeout

Oto co się stało. Dwie console.log linie są synchroniczne, więc biegły jako pierwsze. Obietnica wywołania zwrotnego i queueMicrotask weszły do ​​kolejki mikrozadań i zostały uruchomione, gdy tylko stos się opróżnił, w kolejności, w jakiej zostały dodane. Wywołanie zwrotne timera musiało czekać na turę zadania, mimo że jego opóźnienie wynosiło zero.

Mikrozadania działają pomiędzy timerami

Po każdym pojedynczym zadaniu kolejka mikrozadań jest ponownie opróżniana. Ten przykład to potwierdza:

setTimeout(() => {
  console.log("timer 1");
  Promise.resolve().then(() => console.log("promise inside timer 1"));
}, 0);
setTimeout(() => console.log("timer 2"), 0);

// timer 1
// promise inside timer 1
// timer 2

Obietnica, która została utworzona podczas pierwszego licznika czasu, działała przed drugim licznikiem czasu. Nowoczesne przeglądarki i Node.js 11 i nowsze zachowują się w ten sposób.

Gdzie czekać pasuje

await dzieli funkcję na dwie części. Wszystko przed nim działa synchronicznie, a wszystko po nim jest zaplanowane jako mikrozadanie. To zaskakuje wiele osób:

async function task() {
  console.log("A before await");
  await null;
  console.log("C after await");
}

task();
console.log("B after calling task");

// A before await
// B after calling task
// C after await

Funkcja async nie jest uruchamiana w tle. Działa w tym samym wątku, aż dotrze do pierwszego await. Dotyczy to nawet sytuacji oczekiwania na coś, co nie jest prawdziwą obietnicą, jak na przykład null. Więcej informacji na temat tej składni znajdziesz w naszym przewodniku po asynchronizacji/oczekiwaniu JavaScriptu.

Blokowanie pętli

Podczas działania kodu synchronicznego nic innego nie może. Aby to pokazać, ustawiliśmy timer na 0 ms, a następnie utrzymywaliśmy wątek zajęty przez pół sekundy:

const start = Date.now();
setTimeout(() => console.log("timer ran after", Date.now() - start, "ms"), 0);
while (Date.now() - start < 500) {}

// timer ran after about 500 ms

Opóźnienie timera jest minimalnym, a nie gwarancją. Działał tylko wtedy, gdy stos stał się wolny. Na stronie internetowej taka długa pętla oznacza, że ​​kliknięcia nie odpowiadają, a animacje się zatrzymują. Na serwerze każde inne żądanie musi poczekać, dlatego jedno wolne wywołanie synchroniczne może zaszkodzić wszystkim użytkownikom procesu Node.js.

Typowe przyczyny blokowania obejmują ogromne pętle, analizowanie bardzo dużych plików JSON, synchroniczne funkcje plików, takie jak readFileSync w procedurach obsługi żądań i katastrofalne wyrażenia regularne.

Zachowując responsywność

W przypadku ciężkiej pracy daj pętli zdarzeń szansę odetchnąć. Jednym ze sposobów jest wstrzymywanie od czasu do czasu timera, co pozwala na uruchomienie innych zadań:

const items = [0, 1, 2, 3, 4];

async function processAll() {
  for (const item of items) {
    if (item === 2) await new Promise((r) => setTimeout(r, 0));
    console.log("item", item);
  }
}

setTimeout(() => console.log("other work gets a turn"), 0);
processAll();

// item 0
// item 1
// other work gets a turn
// item 2
// item 3
// item 4

Drugi timer pobiegł w środku, bo ustąpiliśmy przed prawdziwym zadaniem. Prawdziwy kod dawałby co określoną liczbę elementów lub milisekund. W przypadku pracy naprawdę obciążającej procesor, takiej jak przetwarzanie obrazów, użyj procesu roboczego sieci Web w przeglądarkach lub wątku roboczego w Node.js, który działa w oddzielnych wątkach.

Głód mikrozadań

Ponieważ pętla całkowicie opróżnia kolejkę mikrozadań przed przejściem dalej, mikrozadanie, które planuje więcej, może zatrzymać wszystko inne. Przetestowaliśmy to na 100 000 połączonych mikrozadań:

let count = 0;
let timerFired = false;
setTimeout(() => { timerFired = true; }, 0);

function spin() {
  count++;
  if (count < 100000) queueMicrotask(spin);
  else console.log("timer fired during microtasks?", timerFired);
}
queueMicrotask(spin);

// timer fired during microtasks? false

Licznik czasu nie mógł działać, dopóki wszystkie nie zostały ukończone. Gdyby ten łańcuch nigdy się nie skończył, liczniki czasu nigdy by się nie uruchomiły, a w przeglądarce strona nigdy by się nie przemalowała. Zauważ, że poddanie się await w przypadku rozwiązanej obietnicy nie pomaga tutaj, ponieważ po prostu dodaje kolejne mikrozadanie. Potrzebujesz prawdziwego zadania, takiego jak minutnik, aby dać innym szansę.

Renderowanie w przeglądarkach

Przeglądarka zwykle ma szansę na malowanie pomiędzy zadaniami. To wyjaśnia typowy błąd:

spinner.hidden = false;
doHeavyWork();              // blocks the thread
spinner.hidden = true;

Pokrętło nigdy się nie pojawia, ponieważ przeglądarka nie miała możliwości renderowania między tymi liniami. Aby to naprawić, przepuść ramę przed rozpoczęciem ciężkiej pracy lub przenieś ją do pracownika. W przypadku kodu zmieniającego grafikę requestAnimationFrame uruchamia się tuż przed kolejnym malowaniem, co czyni go właściwym narzędziem do animacji.

Różnice w Node.js

Node.js ma własną pętlę zdarzeń z kilkoma fazami, w tym licznikami czasu, odpytywaniem we/wy i setImmediate. Posiada również process.nextTick, który działa we własnej kolejce. Oto, co widzieliśmy, uruchamiając je z poziomu funkcji asynchronicznej:

setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
process.nextTick(() => console.log("nextTick"));
Promise.resolve().then(() => console.log("promise"));

// promise
// nextTick
// immediate
// timeout

W wielu artykułach stwierdza się, że nextTick zawsze dotrzymuje obietnic, a licznik czasu przewyższa setImmediate. Nasz wynik pokazuje, że nie jest to takie proste. Nasz kod był już uruchomiony w ramach mikrozadania, więc kolejka obietnic była kontynuowana jako pierwsza. Wiadomo, że kolejność setTimeout i setImmediate różni się w zależności od tego, skąd są wywoływane. Dlatego nie pisz kodu, który zależy od dokładnej kolejności tych elementów. Jeśli jedna rzecz musi nastąpić po drugiej, połącz je wyraźnie.

Quiz wywiadu

Spróbuj ustalić kolejność, zanim przeczytasz odpowiedź:

console.log("a");
setTimeout(() => console.log("b"), 0);
Promise.resolve().then(() => {
  console.log("c");
  setTimeout(() => console.log("d"), 0);
  Promise.resolve().then(() => console.log("e"));
});
console.log("f");

Nasz przebieg wydrukowano a, f, c, e, b, d. Oto dlaczego:

1. a i f są synchroniczne, więc działają jako pierwsze.
2. Stos jest pusty, zatem uruchamiane są mikrozadania: c, następnie nowe mikrozadanie e, w tej samej rundzie.
3. Teraz jedno zadanie: timer b, który był w kolejce jako pierwszy.
4. Następnie kolejne zadanie: timer d, który ustawił się w kolejce podczas mikrozadania.

Typowe błędy

• Myślenie setTimeout jest dokładne. Opóźnienie jest tylko minimalne.
• Myślenie async oznacza inny wątek. Kod asynchroniczny nadal działa w głównym wątku pomiędzy oczekiwaniami.
• Wykorzystywanie uśpienia do naprawiania kolejności. Oczekiwanie na rzeczywisty stan jest znacznie bardziej niezawodne, co dotyczy również niestabilnych testów.
• Używanie forEach z await. Nie powoduje oczekiwania między elementami. Zobacz Metody tablicowe JavaScript.
• Wykonywanie dużej pracy synchronicznej w programie obsługi serwera. Jedno żądanie może opóźnić każde inne żądanie.

Podsumowanie

Zapamiętaj podstawową zasadę: uruchamiaj stos, aż będzie pusty, uruchom wszystkie mikrozadania, następnie uruchom jedno zadanie i powtórz. Wszystko inne z tego wynika. Aby się utrwaliło, napisz własną wersję powyższego quizu, przewiduj wynik na papierze, a następnie uruchom go. Jeśli popełnisz błąd i zrozumiesz dlaczego, nauczysz się więcej niż jakikolwiek diagram.

Najczęstsze pytania

Ucz się dalej