Comprendre le JavaScript synchrone et asynchrone - 1ère partie

Synchrone et asynchrone sont des concepts confus en JavaScript, en particulier pour les débutants. Deux choses ou plus sont synchrone quand ils arriver en même temps (synchronisé), et asynchrone quand ils ne le font pas (pas synchronisé).

Bien que ces définitions soient faciles à assimiler, c'est en réalité plus compliqué qu'il n'y paraît. Nous devons prendre en compte Qu'est-ce qui est synchronisé?, et ce qui n'est pas.

Vous appelleriez probablement un Ordinaire fonction en JavaScript synchrone, non? Et si c'est quelque chose comme setTimeout () ou AJAX avec lequel vous travaillez, vous allez parler d’asynchrone, oui? Et si je te dis ça tous les deux sont asynchrones d'une manière?

Pour expliquer le Pourquoi, nous devons faire appel à M. X pour obtenir de l'aide.

Scénario 1 - M. X essaie la synchronicité

Voici la configuration:

1. M. X est quelqu'un qui peut répondre à des questions difficiles et effectuer toute tâche demandée..
2. La seule façon de le contacter est par un appel téléphonique.
3. Quelle que soit la question ou la tâche que vous ayez eue, afin de demander l'aide de M. X pour la mener à bien; tu l'appelles.
4. M. X vous donne la réponse ou complète la tâche tout de suite, et vous permet de savoir c'est fait.
5. Vous posez le récepteur et vous sortez pour aller au cinéma.

Ce que tu viens de réaliser était un communication synchrone (aller-retour) avec M. X. Il a écouté pendant que vous lui posiez votre question et vous avez écouté quand il y a répondu.

Scénario 2 - M. X n'est pas content de la synchronicité

Comme M. X est si efficace, il commence à recevoir de nombreux autres appels. Alors, que se passe-t-il lorsque vous l'appelez mais il est déjà occupé parler à quelqu'un d'autre? Vous ne pourrez pas lui poser votre question - pas avant qu'il ne soit libre de recevoir votre appel. Tout ce que vous entendrez est un ton occupé.

Alors, que peut faire M. X pour lutter contre cette?

Au lieu de prendre des appels directement:

1. M. X engage un nouveau type, M. M., et lui donne un répondeur téléphonique pour les appelants. laisser des messages.
2. Le travail de M. M consiste à transmettre un message du répondeur téléphonique à M. X une fois qu'il sait que M. X a complètement terminé le traitement de tous les messages précédents et qu'il est déjà en train de libre d'en prendre un nouveau.
3. Alors maintenant, quand vous l'appelez, au lieu d'avoir une tonalité d'occupation, vous devez laisser un message à M. X, puis attendez qu'il vous rappelle (pas encore l'heure du film).
4. Une fois que M. X aura terminé avec tous les messages en file d'attente qu'il a reçus avant le vôtre, il examinera votre problème et vous rappeler pour vous donner une réponse.

Maintenant se trouve la question: les actions jusqu’à présent synchrone ou asynchrone?

C'est mélangé. Quand tu as laissé ton message, M. X ne l'écoutait pas, donc la quatrième communication était asynchrone.

Mais, quand il a répondu, vous étiez là à écouter, lequel rend la communication de retour synchrone.

J'espère que vous avez maintenant acquis une meilleure compréhension de la façon dont la synchronicité est perçue en termes de communication. Il est temps d'introduire JavaScript.

JavaScript - Un langage de programmation asynchrone

Lorsque quelqu'un qualifie JavaScript asynchrone, ce à quoi ils font référence en général, c'est comment laisser un message pour cela, et ne pas avoir votre appel bloqué avec un ton occupé.

Les appels de fonction sont jamais direct en JavaScript, ils sont littéralement fait via des messages.

JavaScript utilise un file d'attente des messages où les messages entrants (ou événements) sont conservés. Un boucle d'événement (un répartiteur de messages) distribue séquentiellement ces messages à un pile d'appels où les fonctions correspondantes des messages sont empilés comme des cadres (arguments de fonction et variables) pour l'exécution.

La pile d’appel contient la trame de la fonction initiale appelée et toutes les autres trames des fonctions appelées via des appels imbriqués sur le dessus .

Lorsqu'un message rejoint la file d'attente, il attend que la pile d'appels soit vide de toutes les images du message précédent, et quand c'est le cas, la boucle d'événement élimine le message précédent, et ajoute les trames correspondantes du message actuel à la pile d'appels.

Le message attend à nouveau jusqu'à ce que la pile d'appels devienne vide de ses propres cadres correspondants (c’est-à-dire que les exécutions de toutes les fonctions empilées sont terminées), puis est retiré de la file d'attente.

Considérons le code suivant:

 function foo ()  function bar () foo ();  fonction baz () bar ();  baz (); 

La fonction en cours d'exécution est baz () (à la dernière ligne de l'extrait de code), pour lequel un message est ajouté à la file d'attente, et lorsque la boucle d'événement la détecte, la pile d'appels commence à empiler des cadres pour baz (), bar(), et foo () aux points d'exécution concernés.

Une fois que l'exécution des fonctions est terminée une à une, leurs cadres sont retiré de la pile d'appels, pendant que le message est toujours dans la file d'attente, jusqu'à ce que baz () est sorti de la pile.

Rappelez-vous, les appels de fonction sont jamais direct en JavaScript, ils ont fini via des messages. Ainsi, chaque fois que quelqu'un entend dire que JavaScript est un langage de programmation asynchrone, supposons qu'il parle de son langage intégré. “répondeur automatique”, et comment vous êtes libre de laisser des messages.

Mais qu'en est-il des méthodes asynchrones spécifiques?

Jusqu'à présent, je n'ai pas abordé les API telles que setTimeout () et AJAX, ce sont ceux qui sont spécifiquement appelé asynchrone. Pourquoi donc?

Il est important de comprendre ce qui est exactement synchrone ou asynchrone. JavaScript, à l'aide d'événements et de la boucle d'événements, peut s'exercer traitement asynchrone des messages, mais ça ne veut pas dire tout en JavaScript est asynchrone.

Rappelez-vous, je vous ai dit que le message ne partait pas avant que la pile d'appels ne soit vide de ses cadres correspondants, tout comme vous n'êtes pas parti pour un film jusqu'à ce que vous ayez obtenu votre réponse - c'est être synchrone, vous attendez là jusqu'à la fin de la tâche, et vous obtenez la réponse.

Attendre n'est pas idéal dans tous les scénarios. Et si après avoir laissé un message, au lieu d’attendre, vous pouvez partir pour le film? Que se passe-t-il si une fonction peut se retirer (en vidant la pile d'appels) et que son message peut être mis en file d'attente avant même que la tâche de la fonction soit terminée? Et si vous pouviez avoir du code exécuté de manière asynchrone?

C’est là que des API telles que setTimeout () et AJAX entrent en scène, et ce qu'ils font, c'est… attendez, je ne peux pas l'expliquer sans revenir à M. X, ce que nous verrons dans la deuxième partie de cet article. Restez à l'écoute.