Comment le code Node.js s'exécute

Cette fois, je vais vous présenter le principe d'exécution du code Node.js. Quelles sont les précautions lors de l'exécution du code Node.js. Ce qui suit est un cas pratique, jetons un coup d'oeil.

Une fois qu'un logiciel a été téléchargé et installé avec succès, il ne s'agit en fait que d'un ensemble de codes machine, stockés sur le disque dur de notre ordinateur, c'est-à-dire un ensemble de fichiers exe que nous pouvons voir. certains logiciels Il est volumineux et peut être livré avec un tas de fichiers DLL.

Nous avons deux façons d'exécuter ce logiciel :

La plupart des logiciels, tels que QQ, Feiqiu et le navigateur Chrome, peuvent être exécutés et exécutés en double-cliquant dessus.

Certains logiciels doivent être exécutés en ligne de commande, comme notre node.js.

Lorsqu'un logiciel est exécuté, notre système d'exploitation créera un processus correspondant. On peut comprendre que le processus est un logiciel vivant.

Processus et threads

Le cœur de l'ordinateur est le CPU, qui entreprend toutes les tâches informatiques. C'est comme une usine qui fonctionne tout le temps. En supposant que la puissance de l'usine soit limitée, elle ne peut être utilisée que par un seul atelier à la fois. En d’autres termes, lorsqu’un atelier commence à fonctionner, les autres ateliers doivent cesser de fonctionner. La signification derrière cela est qu’un seul processeur ne peut exécuter qu’une seule tâche à la fois. Le processus est comme l'atelier d'une usine. Il représente une tâche unique que le CPU peut gérer à tout moment, le CPU exécute toujours un processus et les autres processus sont dans un état non exécuté. Dans un atelier, plusieurs travailleurs peuvent travailler ensemble pour accomplir une tâche. Les threads sont comme des travailleurs dans un atelier. Un processus peut inclure plusieurs threads. L'espace de l'atelier est partagé par les travailleurs. Par exemple, de nombreuses pièces peuvent être entrées et sorties par chaque travailleur, ce qui signifie que l'espace mémoire d'un processus est partagé et que chaque thread peut utiliser ces mémoires partagées. Cependant, la taille de chaque pièce est différente. Certaines pièces peuvent accueillir au maximum une personne, comme les toilettes, lorsqu'il y a quelqu'un à l'intérieur, les autres personnes ne peuvent pas entrer. Cela signifie que lorsqu'un thread utilise de la mémoire partagée, les autres threads doivent attendre qu'il se termine avant de pouvoir utiliser cette mémoire.
Un moyen simple d'empêcher les autres d'entrer est d'ajouter une serrure à la porte. Les personnes qui arrivent en premier verrouillent la porte. Les personnes qui arrivent plus tard voient la serrure et font la queue devant la porte. entrer. C’est ce qu’on appelle un verrouillage d’exclusion mutuelle.

Pourquoi JavaScript est-il monothread ?

Une caractéristique majeure du langage JavaScript est qu'il est monothread, ce qui signifie qu'il ne peut faire qu'une seule chose à la fois. Alors pourquoi JavaScript ne peut-il pas avoir plusieurs threads ? Cela peut améliorer l’efficacité.

Le fil de discussion unique de JavaScript est lié à son objectif. En tant que langage de script de navigateur, l'objectif principal de JavaScript est d'interagir avec les utilisateurs et de manipuler le DOM. Cela détermine qu'il ne peut être qu'un seul thread, sinon cela entraînera des problèmes de synchronisation très complexes. Par exemple, supposons que JavaScript ait deux threads en même temps. Un thread ajoute du contenu à un certain nœud DOM et l'autre thread supprime ce nœud. Dans ce cas, quel thread le navigateur doit-il utiliser ?

Ainsi, afin d'éviter toute complexité, JavaScript est monothread depuis sa naissance. Cela est devenu la fonctionnalité principale de ce langage et ne changera pas à l'avenir.

JavaScript est monothread. Bien qu'il existe des travailleurs, des clusters, etc. qui peuvent implémenter le multi-threading, ceux-ci sont utilisés pour créer des threads avec des fonctions limitées et sont toujours contrôlés par le thread principal. JavaScript Il s'agit d'un seul thread.

De plus, nous devons comprendre que JavaScript est monothread, ce qui ne signifie pas que Node.js est également monothread. Une fois que Node.js a exécuté une instance, il est monoprocessus et multi-thread. threadé. Il contient un thread. Le moteur V8 est responsable de l'analyse de JavaScript, et certains threads sont responsables de libuv, ce que nous entendons par boucle d'événements.

Comment comprendre IO :

I représente une entrée, une entrée : comme lire un fichier, lancer une requête ajax de données
O représente une sortie, une sortie : comme écrire un fichier

🎜 >

Synchronique vs Asynchrone

Comme ce qui suit, qui n'implique pas la lecture et l'écriture de fichiers, les requêtes réseau ou les minuteries, il s'agit uniquement de code synchrone :

var a = 1;var b = 2;function fn(){}

Ce qui suit est du code asynchrone :

fs.readFile('./a.js',callback);
fs.writeFile('./b.js',callback);

Y compris un tas d'événements de souris, de clavier, ajax, etc. que nous voyons du côté du navigateur.

La plupart des objets asynchrones de Node.js sont hérités de l'objet événement event.eventEmitter

Comprendre le mécanisme d'exécution du code de Node.js

Nous pouvons mettre Node Imagine le processus .js est comme un restaurant :

Le chef représente le thread principal JavaScript. Il est constamment occupé à exécuter le code de synchronisation sur le thread principal jusqu'à ce que l'exécution soit terminée.

//同步代码var a = 1;//同步代码var b = 2;//异步代码fs.readFile('./a.js',function(err,data){    if(err)throw data;
});//同步代码var c = 3;//异步代码setTimeout(function(){
},200);//同步代码console.log(a + b + c);//同步代码function fn(){    console.log('abc');
}//异步代码fs.writeFile('./b.js',myData,function(err){    if(err)throw err;
});

Par exemple, le code comme celui ci-dessus est exécuté de haut en bas. Lorsqu'il rencontre du code synchrone, il est directement remis au chef pour qu'il le termine. non exécuté à ce moment-là, au lieu de cela, il est remis à notre serveur comme un nouvel invité, et le serveur enregistre le plat commandé par l'invité, ce qui équivaut à traiter ce code asynchrone comme un événement et à l'enregistrer dans notre file d'attente des événements. .

Lorsque presque tous les codes de synchronisation auront été exécutés, le thread principal sera inactif. À ce moment, notre fil de boucle d'événements sera démarré et ce fil de boucle d'événements commencera à vérifier quels invités ont été enregistrés par le serveur. Après avoir commandé les plats, nous commencerons à frire leurs plats un par un par ordre de priorité, c'est-à-dire à exécuter nos codes asynchrones, car il y a beaucoup d'invités et les exigences de chaque invité sont différentes, comme notre code Node.js a différents types de code asynchrone, tel que les minuteries, la lecture de fichiers, la récupération de fichiers et les requêtes réseau, Node.js dispose donc de nombreux pools de threads pour gérer ces codes asynchrones.

Lorsque l'exécution asynchrone d'un thread dans le pool de threads est terminée, cela équivaut à la fin de l'événement, et la fonction de rappel correspondant à l'événement sera mise en file d'attente derrière le thread principal .

Une fois qu'il y a du nouveau code à exécuter sur le thread principal, le chef commence à travailler dès qu'il voit qu'il y a quelque chose à faire.

Si le code correspondant à la fonction de rappel exécutée sur le thread principal génère un nouveau code asynchrone, celui-ci sera inscrit dans la boucle d'événements.

Jusqu'à un certain moment, tous les événements de la file d'attente des événements sont exécutés et le pool de threads se vide lentement.

node.js appellera process.exit() et le système d'exploitation détruira le processus node.js actuel.

Il suffit fondamentalement de comprendre ce qui précède, allons plus loin :

Quand nous arrivons au point d'apprendre la programmation réseau, nous savons que lorsque nous connaissons un conteneur de serveur, à moins que nous prendre l'initiative Utilisez CTRL + C pour terminer le processus en cours, sinon il attendra la connexion client et effectuera le traitement correspondant selon l'itinéraire correspondant.

Comment comprenez-vous cela ?

Rappelons l'API que nous avons apprise dans jQuery. Il existe deux manières de surveiller les événements :

une surveillance ponctuelle

sur une surveillance illimitée

Nous. peut comprendre de cette façon : la plupart des opérations sur les fichiers, ajax, etc., ne doivent en fait être effectuées qu'une seule fois et il n'y aura pas de deuxième fois. Elles sont équivalentes à un modèle d'événement à un seul type.

Mais s'il s'agit de programmation réseau comme socket, http, etc., cela équivaut à une surveillance illimitée sur.

Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !

Lecture recommandée :

Le concept d'utilisation de portées indépendantes en angulaire

Explication détaillée de l'utilisation de $apply( ) dans angulairejs

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!