Thread pool comment quand et qui a utilisé:
Tout d'abord, lorsque nous utilisons / installons Node sur un ordinateur, il démarre un processus parmi d'autres processus qui est appelé processus de nœud dans l'ordinateur, et il continue de fonctionner jusqu'à ce que vous le tuiez. Et ce processus en cours est notre soi-disant thread unique.
Donc, le mécanisme de thread unique facilite le blocage d'une application de nœud, mais c'est l'une des fonctionnalités uniques que Node.js apporte à la table. Donc, encore une fois, si vous exécutez votre application de nœud, elle ne fonctionnera que dans un seul thread. Peu importe si vous avez 1 ou un million d'utilisateurs accédant à votre application en même temps.
Comprenons donc exactement ce qui se passe dans le thread unique de nodejs lorsque vous démarrez votre application de nœud. Au début, le programme est initialisé, puis tout le code de niveau supérieur est exécuté, ce qui signifie que tous les codes qui ne sont dans aucune fonction de rappel ( rappelez-vous que tous les codes à l'intérieur de toutes les fonctions de rappel seront exécutés sous la boucle d'événement ).
Après cela, tous les modules code exécutés puis enregistrent tous les rappels, enfin, la boucle d'événement lancée pour votre application.
Ainsi, comme nous le verrons avant, toutes les fonctions de rappel et les codes à l'intérieur de ces fonctions s'exécuteront sous une boucle d'événement. Dans la boucle d'événements, les charges sont réparties en différentes phases. Quoi qu'il en soit, je ne vais pas discuter de la boucle d'événements ici.
Eh bien, pour mieux comprendre le pool de threads, je vous demande d'imaginer que dans la boucle d'événements, les codes à l'intérieur d'une fonction de rappel s'exécutent après avoir terminé l'exécution de codes dans une autre fonction de rappel, maintenant s'il y a des tâches en fait trop lourdes. Ils bloqueraient alors notre thread unique nodejs. Et donc, c'est là que le pool de threads entre en jeu, qui est tout comme la boucle d'événements, est fourni à Node.js par la bibliothèque libuv.
Ainsi, le pool de threads ne fait pas partie de nodejs lui-même, il est fourni par libuv pour décharger de lourdes tâches sur libuv, et libuv exécutera ces codes dans ses propres threads et après l'exécution, libuv retournera les résultats à l'événement dans la boucle d'événements.
Le pool de threads nous donne quatre threads supplémentaires, ceux-ci sont complètement séparés du thread unique principal. Et nous pouvons en fait le configurer jusqu'à 128 threads.
Donc, tous ces threads forment ensemble un pool de threads. et la boucle d'événements peut alors automatiquement décharger les tâches lourdes vers le pool de threads.
La partie amusante est que tout cela se produit automatiquement dans les coulisses. Ce ne sont pas nous les développeurs qui décidons de ce qui va au pool de threads et de ce qui ne l'est pas.
Il existe de nombreuses tâches qui vont au pool de threads, telles que
-> All operations dealing with files
->Everyting is related to cryptography, like caching passwords.
->All compression stuff
->DNS lookups