{"id":3459,"date":"2019-04-24T08:53:00","date_gmt":"2019-04-24T08:53:00","guid":{"rendered":"http:\/\/the-codest.localhost\/blog\/mom-he-blocked-threads-again\/"},"modified":"2026-04-24T11:21:40","modified_gmt":"2026-04-24T11:21:40","slug":"maman-il-a-encore-bloque-des-fils-de-discussion","status":"publish","type":"post","link":"https:\/\/thecodest.co\/fr\/blog\/mom-he-blocked-threads-again\/","title":{"rendered":"MOM ! Il a encore bloqu\u00e9 des fils !"},"content":{"rendered":"

Fils<\/h2>\n

Principale chose \u00e0 retenir : il y a deux types de fils dans Node.js<\/a><\/strong>: Main Thread - qui est g\u00e9r\u00e9 par Boucle d'\u00e9v\u00e9nements<\/b>et R\u00e9serve de travailleurs<\/b> (thread pool) - qui est le pool de threads - (threads pool)
\ngr\u00e2ce \u00e0 libuv<\/a>. Chacun d'entre eux a une t\u00e2che diff\u00e9rente. L'objectif du premier est de g\u00e9rer les op\u00e9rations d'E\/S non bloquantes, et le second est responsable des travaux intensifs de l'unit\u00e9 centrale et des E\/S bloquantes.<\/p>\n

\"diagramme<\/p>\n

Mais qu'est-ce qu'un fil et en quoi est-il diff\u00e9rent d'un processus ? Il y a plusieurs diff\u00e9rences, mais la plus importante pour l'utilisateur est la suivante nous<\/a> est la mani\u00e8re dont la m\u00e9moire leur est allou\u00e9e. Vous pouvez consid\u00e9rer un processus comme une application. \u00c0 l'int\u00e9rieur de chaque processus, il y a un morceau de m\u00e9moire d\u00e9di\u00e9 uniquement \u00e0 ce processus. Ainsi, un processus n'a pas acc\u00e8s \u00e0 la m\u00e9moire du second, et cette propri\u00e9t\u00e9 garantit une grande s\u00e9curit\u00e9. Pour \u00e9tablir une communication entre eux, nous devons effectuer un certain travail. Les threads sont diff\u00e9rents. Les threads s'ex\u00e9cutent \u00e0 l'int\u00e9rieur d'un processus et partagent la m\u00eame m\u00e9moire ; il n'y a donc aucun probl\u00e8me de partage de threads. donn\u00e9es<\/a>.<\/p>\n

Cependant, un point pose probl\u00e8me. Il s'agit de la condition de course. Les threads peuvent s'ex\u00e9cuter en m\u00eame temps, alors comment savoir lequel se termine en premier ? Il se peut que la premi\u00e8re fois que vous l'ex\u00e9cutez, la premi\u00e8re op\u00e9ration se termine en premier, et que la fois suivante, ce soit l'inverse et que la deuxi\u00e8me op\u00e9ration se termine avant la premi\u00e8re. Imaginez que vous travailliez avec des op\u00e9rations d'\u00e9criture\/lecture dans de telles conditions ! Un cauchemar ! Il est parfois tr\u00e8s difficile d'\u00e9crire des code<\/a> dans un environnement multithread.<\/p>\n

De plus, les langages multithreads ont une surcharge de m\u00e9moire importante parce qu'ils cr\u00e9ent un thread s\u00e9par\u00e9 pour chaque requ\u00eate ; ainsi, si vous voulez appeler 1000 requ\u00eates, ils cr\u00e9ent 1000 threads.<\/p>\n

Comment r\u00e9soudre ce probl\u00e8me ? Utilisez plut\u00f4t un fil unique ! Et c'est ce que N\u0153ud<\/a><\/strong> vous offre.<\/p>\n

\"boucle<\/p>\n

En tant que D\u00e9veloppeur JavaScript<\/a><\/strong> Je vous encourage \u00e0 regarder le film<\/a>
\ndans lequel Bart Belder explique clairement le concept de boucle d'\u00e9v\u00e9nements. Le diagramme ci-dessus est extrait de sa pr\u00e9sentation. Et si vous ne connaissez pas du tout ces termes, vous pouvez consulter les deux documents suivants N\u0153ud<\/strong> et Libuv disposent d'une excellente documentation \ud83d\ude42 .<\/p>\n

A propos du blocage<\/h2>\n

En JavaScript<\/a> d\u00e9veloppement<\/strong> l'industrie, ils disent que parce que N\u0153ud<\/strong> est monot\u00e2che et non bloquant, vous pouvez atteindre une plus grande concurrence avec les m\u00eames ressources qu'avec des solutions multithreads. C'est vrai, mais ce n'est pas aussi beau et facile qu'il n'y para\u00eet.<\/p>\n

Depuis Node.js<\/strong> est \u00e0 un seul fil (JS<\/a> ), les t\u00e2ches \u00e0 forte intensit\u00e9 de CPU bloqueront toutes les demandes en cours jusqu'\u00e0 ce que la t\u00e2che en question soit termin\u00e9e. Il est donc vrai qu'en Node.js<\/strong> vous pouvez bloquer toutes les requ\u00eates simplement parce que l'une d'entre elles contient une instruction bloquante. Le code bloquant signifie qu'il faut plus de quelques millisecondes pour terminer. Mais il ne faut pas confondre temps de r\u00e9ponse long et blocage. La r\u00e9ponse de la base de donn\u00e9es peut \u00eatre tr\u00e8s longue, mais elle ne bloque pas votre processus (application).<\/p>\n

Les m\u00e9thodes bloquantes s'ex\u00e9cutent de mani\u00e8re synchrone et les m\u00e9thodes non bloquantes s'ex\u00e9cutent de mani\u00e8re asynchrone.<\/p>\n

Comment ralentir (ou bloquer) votre boucle d'\u00e9v\u00e9nements ?<\/p>\n