{"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":"mamma-ha-bloccato-di-nuovo-i-thread","status":"publish","type":"post","link":"https:\/\/thecodest.co\/it\/blog\/mom-he-blocked-threads-again\/","title":{"rendered":"MAMMA! Ha bloccato di nuovo le discussioni!"},"content":{"rendered":"

Fili<\/h2>\n

La cosa principale da ricordare \u00e8 che ci sono due tipi di thread in Node.js<\/a><\/strong>: Thread principale - che viene gestito da Ciclo di eventi<\/b>, e Pool di lavoratori<\/b> (pool di thread) - che \u00e8 il pool di thread
\ngrazie a libuv<\/a>. Ognuno di essi ha un compito diverso. L'obiettivo del primo \u00e8 gestire le operazioni di I\/O non bloccanti, mentre il secondo \u00e8 responsabile del lavoro intensivo della CPU e anche dell'I\/O bloccante.<\/p>\n

\"diagramma<\/p>\n

Ma cos'\u00e8 una filettatura e in cosa si differenzia da un processo? Ci sono diverse differenze, ma la pi\u00f9 importante per noi<\/a> \u00e8 il modo in cui viene allocata la memoria. Si pu\u00f2 pensare a un processo come a un'applicazione. All'interno di ogni processo, c'\u00e8 una porzione di memoria dedicata solo a questo processo. Quindi, un processo non ha accesso alla memoria del secondo e questa propriet\u00e0 garantisce un'elevata sicurezza. Per stabilire una comunicazione tra i due processi, dobbiamo fare un po' di lavoro. I thread sono diversi. I thread vengono eseguiti all'interno di un processo e condividono la stessa memoria, quindi non c'\u00e8 alcun problema con la condivisione dei thread. dati<\/a>.<\/p>\n

Tuttavia, una questione causa un problema. Si tratta della cosiddetta condizione di gara. I thread possono essere eseguiti contemporaneamente, quindi come facciamo a sapere quale termina per primo? Pu\u00f2 accadere che la prima volta che si esegue, la prima operazione termini per prima, mentre la volta successiva pu\u00f2 accadere il contrario e che la seconda operazione termini prima della prima. Immaginate di lavorare con operazioni di scrittura\/lettura in queste condizioni! Un incubo! A volte \u00e8 molto difficile scrivere operazioni corrette codice<\/a> in un ambiente multi-thread.<\/p>\n

Inoltre, i linguaggi multi-thread hanno un grande overhead di memoria perch\u00e9 creano un thread separato per ogni richiesta; quindi, se si vogliono chiamare 1000 richieste, creano 1000 thread.<\/p>\n

Come affrontare un simile problema? Utilizzando invece un singolo thread! E questo \u00e8 ci\u00f2 che Nodo<\/a><\/strong> vi offre.<\/p>\n

\"singolo<\/p>\n

Come Sviluppatore JavaScript<\/a><\/strong> Vi invito a guardare il film<\/a>
\nin cui Bart Belder spiega chiaramente il concetto di ciclo di eventi. Il diagramma qui sopra \u00e8 tratto dalla sua presentazione. E se non conoscete affatto questi termini, sia Nodo<\/strong> e Libuv hanno una documentazione eccellente \ud83d\ude42<\/p>\n

Informazioni sul blocco<\/h2>\n

In JavaScript<\/a> sviluppo<\/strong> dicono che perch\u00e9 Nodo<\/strong> \u00e8 a thread singolo e non bloccante, si pu\u00f2 ottenere una maggiore concurrency con le stesse risorse rispetto alle soluzioni multi-thread. \u00c8 vero, ma non \u00e8 cos\u00ec bello e facile come pu\u00f2 sembrare.<\/p>\n

Da quando Node.js<\/strong> \u00e8 a thread singolo (JS<\/a> parte), i task ad alta intensit\u00e0 di CPU bloccheranno tutte le richieste in corso fino al completamento di quel particolare task. Quindi, \u00e8 vero che in Node.js<\/strong> \u00e8 possibile bloccare ogni richiesta solo perch\u00e9 una di esse contiene un'istruzione bloccante. Il codice bloccante significa che richiede pi\u00f9 di qualche millisecondo per essere completato. Ma non bisogna confondere i tempi di risposta lunghi con il blocco. La risposta del database pu\u00f2 richiedere molto tempo, ma non blocca il processo (l'applicazione).<\/p>\n

I metodi bloccanti vengono eseguiti in modo sincrono e quelli non bloccanti in modo asincrono.<\/p>\n

Come si pu\u00f2 rallentare (o bloccare) il ciclo degli eventi?<\/p>\n