Al Mòdul 1 vas fer servir Node.js com una caixa negra: vas escriure node src/cataleg.js i van aparèixer esdeveniments per pantalla. Va funcionar, però no saps què hi ha dins d'aquesta caixa. I aquest desconeixement té conseqüències molt concretes: no sabries explicar per què un servidor Node aguanta deu mil connexions simultànies amb un sol procés, per què llegir un fitxer gran no bloqueja ningú però calcular un hash sí, ni per què el consell «no bloquegis el fil principal» es repeteix fins a l'avorriment en tota la documentació.

Aquesta lliçó obre la caixa. Veurem les capes reals que componen Node.js —el teu JavaScript, la biblioteca estàndard, els bindings, V8 i libuv—, què fa exactament cadascuna, i el matís que gairebé tothom repeteix malament: Node.js no és d'un sol fil del tot. Hi ha un fil principal on viu el teu codi i un grup de fils auxiliars on passen coses que tu no veus mai. En acabar sabràs quines operacions van a cada lloc, ho podràs mesurar amb experiments executables, i entendràs per què bloquejar el fil principal és el pecat capital del desenvolupament en Node.

És la base sobre la qual s'aguanta tota la resta del mòdul. Sense ella, el bucle d'esdeveniments de la lliçó següent és màgia; amb ella, és mecànica.

1. La pila de Node.js capa per capa
2. V8: el motor que executa el teu JavaScript
3. libuv: el motor que fa possible l'asincronia
4. El matís clau: Node no és d'un sol fil del tot
5. Què va al thread pool i què no
6. Demostració mesurable: els quatre fils i el cinquè que espera
7. El pecat capital: bloquejar el fil principal
8. El cicle de vida d'un procés Node
9. Inspeccionar el procés: process.version i process.memoryUsage()

Quan executes node src/cataleg.js, aquesta ordre posa en marxa un programa escrit en C++ que conté, empaquetats dins del mateix binari, un motor de JavaScript i una biblioteca d'entrada/sortida asíncrona. El teu fitxer .js és, simplement, la dada d'entrada d'aquest programa.

Aquestes són les capes, de dalt a baix:

Anem capa per capa amb un exemple concret: la crida fs.readFile('dades/esdeveniments.json', callback) que escriuràs de debò al Mòdul 3.

Dues idees importants d'aquesta taula:

• Bona part de Node.js està escrita en JavaScript, no pas en C++. Els mòduls fs, http, path, events, stream… són fitxers .js incrustats dins del binari. Els pots llegir: són al repositori de Node, a la carpeta lib/. Això vol dir que la biblioteca estàndard de Node és, en gran mesura, codi com el teu.
• Els bindings són la frontera. Tot allò que JavaScript no pot fer per si sol —obrir un socket, llegir un fitxer, xifrar— travessa aquesta frontera cap a C++. Travessar-la té un cost petit però no nul, i per això convé fer poques crides grans en comptes de moltes de petites.

Comprovació ràpida. Node exposa quines versions de cada dependència porta a dins. Executa això al teu terminal:

node -p "JSON.stringify(process.versions, null, 2)"

Veuràs una cosa semblant a { "node": "22.11.0", "v8": "12.4.254.21", "uv": "1.48.0", "openssl": "3.0.15", "zlib": "1.3.1", ... }. Cadascuna d'aquestes línies és una de les biblioteques del diagrama.

V8 és el motor de JavaScript de Google, el mateix que fa servir Chrome. La seva feina és una de sola: convertir el teu codi JavaScript en instruccions de màquina i executar-les. V8 no sap res de fitxers, ni de xarxa, ni de temporitzadors. Això no forma part de JavaScript; ho posa Node.

V8 fa tres coses que t'afecten directament.

JavaScript no s'interpreta línia a línia com als anys noranta. V8 fa servir una canonada de diverses etapes:

1. Anàlisi i bytecode. Un intèrpret anomenat Ignition converteix el teu codi en un bytecode compacte i l'executa. És ràpid d'arrencar però moderat en velocitat.
2. Observació. Mentre s'executa, V8 registra quines funcions es criden molt i amb quins tipus de dades.
3. Optimització. Un compilador optimitzador (TurboFan) agafa les funcions «calentes» i genera codi màquina especialitzat per als tipus que ha observat.
4. Desoptimització. Si de sobte crides aquesta funció amb un tipus diferent del previst, V8 descarta el codi optimitzat i torna al bytecode.

La conseqüència pràctica per a tu: la coherència de tipus importa. Una funció que de vegades rep un número i de vegades una cadena és més lenta que una que sempre rep un número.

Aquesta és una altra raó —a banda de l'exactitud dels diners— per a la nostra convenció de desar els imports sempre com a enters de cèntims: cada camp té un únic tipus durant tota la seva vida.

V8 gestiona la memòria de tots els teus objectes en una zona anomenada munt, dividida en dues regions:

La hipòtesi en què es basa aquest disseny és que la majoria dels objectes moren joves. A Escena Viva, l'objecte temporal que crees per formatar una data mor en microsegons; l'array cataleg viu tot el procés. Separar-los permet netejar allò efímer molt barat.

En JavaScript no alliberes memòria a mà: V8 detecta quins objectes ja no són accessibles des de cap variable viva i en recupera l'espai. El que has de saber:

• La recol·lecció d'escombraries pausa l'execució del teu JavaScript. Les pauses de la nova generació són de microsegons i no es noten; les de la vella generació poden ser de mil·lisegons i sí que es noten en un servidor carregat.
• El munt té un límit. Per defecte ronda els 4 GB en versions modernes de 64 bits, i s'ajusta amb node --max-old-space-size=2048. Si el superes, el procés mor amb JavaScript heap out of memory.
• Es poden tenir fuites de memòria en JavaScript. No pas per oblidar-te d'alliberar, sinó per continuar referint-te a coses que ja no necessites: una memòria cau que creix sense límit, un array que només acumula, o —cas molt típic i que veurem a la lliçó Esdeveniments i EventEmitter— oients que es registren i no es desregistren mai.

Si V8 aporta l'«executar JavaScript», libuv aporta el «fer-ho sense esperar». És una biblioteca escrita en C, nascuda precisament per a Node.js, l'objectiu de la qual és oferir una única API asíncrona multiplataforma per damunt de mecanismes de sistema operatiu que són completament diferents entre si.

libuv té tres responsabilitats:

1. El bucle d'esdeveniments (event loop). El cicle infinit que pregunta «hi ha res acabat? hi ha cap callback per executar?» i va processant la feina pendent. És tan central que li dediquem sencera la lliçó següent, El Bucle d'Esdeveniments (Event Loop).
2. L'E/S asíncrona del sistema operatiu. Per a la xarxa, libuv fa servir el mecanisme natiu de notificació de cada plataforma: epoll a Linux, kqueue a macOS i BSD, event ports a Solaris i IOCP a Windows. Amb aquests mecanismes, un sol fil pot vigilar milers de sockets alhora sense consumir un fil per connexió.
3. La cua de treball i el thread pool. Per a les operacions que el sistema operatiu no ofereix de manera asíncrona fiable, libuv manté un grup de fils reals als quals envia la feina. És la part que genera més malentesos i la que veurem en detall tot seguit.

Llegeix el diagrama en veu alta un cop: el teu codi demana una cosa, libuv decideix per quin camí resoldre-la, la feina es fa fora del teu fil i, quan acaba, el resultat torna al teu fil en forma de callback. Aquest viatge d'anada i tornada és tota l'asincronia de Node.

La frase «Node.js és d'un sol fil» es repeteix arreu i és mitja veritat. La versió precisa és:

El teu codi JavaScript s'executa en un únic fil. La feina d'entrada/sortida, no.

Si obres el monitor de processos mentre corre un programa Node, veuràs que el procés té diversos fils: el principal, els quatre del thread pool, i alguns més de V8 per a la recol·lecció d'escombraries i la compilació en segon pla.

Comprova-ho tu mateix:

A macOS pots fer servir ps -M <pid>; a Windows, l'Administrador de tasques amb la columna «Subprocessos» activada.

El que això significa a la pràctica:

L'avantatge que el teu JavaScript sigui monofil és enorme i sovint s'oblida: no existeixen condicions de carrera dins d'un bloc de codi síncron. Quan a Escena Viva escriguis sessio.venudes += quantitat, ningú no es pot colar entre la lectura i l'escriptura. En Java o en Go hauries de pensar en un pany; aquí, no. El preu d'aquesta tranquil·litat és que tu ets responsable de tornar el control de pressa.

Aquesta és probablement la taula més útil de la lliçó. El thread pool de libuv té 4 fils per defecte i es configura amb la variable d'entorn UV_THREADPOOL_SIZE (màxim 1024 en versions modernes).

Fixa't en el detall del DNS: dns.lookup i dns.resolve no són sinònims. dns.lookup és el que fa servir per sota http.request quan li dones un nom de host, i consumeix un fil del thread pool. És un clàssic: una aplicació que fa moltes peticions HTTP sortints exhaureix els quatre fils amb resolucions de DNS i, de sobte, les lectures de fitxer es tornen lentes sense motiu aparent.

I fixa't en l'última fila, perquè és la que resumeix la lliçó: per al càlcul en JavaScript no hi ha sortida. El thread pool només serveix el codi natiu de Node. Si tu escrius un bucle que triga dos segons, aquests dos segons els paga el fil principal.

Prou teoria. Anem a mesurar el thread pool. Farem servir crypto.pbkdf2, una funció de derivació de claus (la mateixa família que farem servir al Mòdul 8 per a les contrasenyes) que consumeix CPU de manera intensiva i que libuv envia al thread pool.

Crea src/laboratori/thread-pool.js:

Executa:

Sortida típica (els mil·lisegons variaran segons la teva màquina, però el patró serà el mateix):

Llegeix bé aquest resultat, perquè conté tota la lliçó:

• Les quatre primeres tasques acaben gairebé alhora, al voltant dels 170 ms. S'han executat en paral·lel de debò, cadascuna en un fil del thread pool, en quatre nuclis diferents del teu processador.
• La cinquena triga aproximadament el doble. No hi havia un cinquè fil lliure: ha hagut d'esperar en cua que un dels quatre s'alliberés.

Ara puja la mida del thread pool i torna a executar-lo:

Les cinc acaben alhora. Acabes de comprovar experimentalment la mida del thread pool i el seu efecte.

Compte amb la temptació de pujar-lo molt. UV_THREADPOOL_SIZE=128 no multiplica el rendiment per 32: si la teva màquina té 8 nuclis, 128 fils competeixen pels mateixos 8 nuclis i afegeixen cost de canvi de context. La regla raonable és acostar-lo al nombre de nuclis quan la teva aplicació fa molta E/S de fitxers o molt crypto, i mesurar sempre abans i després. La variable ha d'estar posada abans d'arrencar el procés: canviar-la des de dins amb process.env.UV_THREADPOOL_SIZE = 8 no té cap efecte, perquè el pool ja s'ha creat.

Ara l'experiment complementari, i el més important de la lliçó. Què passa si la feina pesada la fas en JavaScript en comptes de delegar-la?

Crea src/laboratori/bloqueig.js:

Executa node src/laboratori/bloqueig.js:

Mira el forat: entre els 205 ms i els 1306 ms no hi va haver ni un sol batec. Durant un segon sencer el procés va estar viu però completament sord. Els temporitzadors no es van disparar i, si hagués estat un servidor HTTP, cap petició no s'hauria atès: s'haurien quedat a la cua del sistema operatiu esperant que el fil principal tornés a estar lliure.

Traduït a Escena Viva: si un usuari demana un informe que triga un segon a calcular-se de manera síncrona, els altres tres-cents usuaris que estan comprant entrades en aquell moment esperen també aquest segon. No és que la seva petició sigui més lenta; és que el servidor sencer s'ha aturat.

Aquesta és la diferència fonamental amb el model d'un fil per petició que vas veure a la primera lliçó: allà, una petició lenta perjudica només qui l'ha feta. Aquí perjudica tothom. És el preu de l'eficiència del model de Node, i explica la regla que governarà la resta del curs:

Tot el que facis al fil principal ha de durar poc. El que duri molt, delega-ho.

Les maneres de delegar, per ordre de preferència:

És exactament la promesa que es va fer a la lliçó Què és Node.js? quan vam dir que el càlcul intensiu de CPU era el punt feble de Node i que el Mòdul 10 ho resoldria. Ara ja saps per què és el punt feble.

Queda una pregunta que potser no t'havies fet: quan vas executar node src/cataleg.js, el programa va imprimir el catàleg i va acabar sol. Però si executes node -e "setInterval(() => {}, 1000)", el procés no acaba mai. Qui ho decideix?

El cicle de vida d'un procés Node té aquestes etapes:

La clau és al rombe del pas 4. libuv porta un compte de referències de les tasques actives: temporitzadors programats, sockets oberts, operacions de fitxer en curs, servidors escoltant. Mentre aquest compte sigui més gran que zero, el bucle continua girant. Quan arriba a zero, no queda res que pugui passar mai, així que Node tanca ordenadament i torna el control al terminal.

Això explica els dos casos:

Un setInterval, en canvi, no allibera mai la seva referència perquè sempre hi ha una propera execució programada: el procés viu per sempre fins que algú cridi clearInterval o el matis amb Ctrl+C. El mateix passa amb un servidor HTTP escoltant, i és justament el que volem: un servidor que es tanqués sol no serviria de gaire.

Hi ha una via d'escapament, unref(), que marca una tasca com a «no compta per mantenir viu el procés»:

És el patró habitual de les tasques de vigilància i mètriques: vols que informin mentre l'aplicació visqui, però no que la mantinguin viva.

I per acabar, la sortida forçada:

Ja vas fer servir process.exitCode a la lliçó El Teu Primer Programa en Node.js; ara ja saps per què es prefereix a process.exit().

Node et deixa mirar dins seu en temps d'execució. Dues eines que faràs servir constantment.

process.version (singular, amb v al davant) és la versió de Node; process.versions (plural) és l'objecte amb totes les dependències. Es confonen constantment.

Un ús real: comprovar en arrencar que es compleix la versió mínima que el projecte necessita.

Recorda la convenció del projecte: el diagnòstic va per stderr (console.error), les dades per stdout.

process.memoryUsage() retorna un objecte amb el consum actual, en bytes:

Què mesura cada camp:

Fixa't en la tercera línia de l'exemple: la memòria no va baixar en buidar l'array. No és cap error. La recol·lecció d'escombraries no és immediata: V8 recuperarà aquest espai quan li convingui, no pas quan tu deixis de fer servir els objectes. Per això, per diagnosticar fuites, no miris mai una mesura aïllada: mira la tendència de heapUsed al llarg de minuts o hores. Una línia que puja i baixa és sana; una que només puja és una fuita.

Al Mòdul 11 convertirem aquesta mesura manual en mètriques publicades de manera contínua.

Error 1: creure que Node és literalment monofil i que per això no pot aprofitar diversos nuclis. Mitja veritat. El teu JavaScript és monofil, però l'E/S de fitxers, el DNS i crypto sí que fan servir diversos nuclis a través del thread pool. El que no es paral·lelitza sol és el teu codi.

Error 2: fer servir les versions ...Sync en un servidor. fs.readFileSync en un script d'una sola execució és perfectament raonable. Dins d'un gestor de peticions HTTP és un error greu: bloqueja tots els usuaris mentre el disc respon.

Error 3: pujar UV_THREADPOOL_SIZE a la brava. Més fils que nuclis genera competència i canvis de context. Mesura abans de tocar-ho, i recorda que cal posar-ho abans d'arrencar el procés.

Error 4: confondre process.version amb process.versions. La primera és una cadena ('v22.11.0'), la segona un objecte. process.versions.node sí que és equivalent a la primera, però sense la v.

Error 5: cridar process.exit() per «acabar bé». Talla el procés en sec. Si hi havia un fitxer escrivint-se o una resposta HTTP a mig enviar, es perden. Fes servir process.exitCode i deixa que el bucle acabi sol.

Error 6: diagnosticar una fuita de memòria amb una sola mesura. heapUsed puja i baixa constantment pel funcionament mateix del recol·lector. Només la tendència sostinguda és senyal de fuita.

Consell 1: memoritza la pregunta. Davant de qualsevol operació, pregunta't: «això és E/S o és càlcul?». Si és E/S, hi ha una versió asíncrona i l'has de fer servir. Si és càlcul llarg en JavaScript, no hi ha màgia: o l'optimitzes, o el mous a un worker, o el treus del procés.

Consell 2: tingues a mà l'script del batec. El setInterval que imprimeix cada 100 ms és la manera més barata de saber si alguna cosa està bloquejant el teu procés. A la lliçó següent el convertirem en una mesura formal del retard del bucle d'esdeveniments.

Consell 3: llegeix el codi font de Node. Com que bona part de la biblioteca estàndard és JavaScript, lib/fs.js o lib/events.js al repositori de Node són perfectament llegibles i ensenyen moltíssim.

Amplia src/laboratori/thread-pool.js perquè, a més del que ja fa, imprimeixi al final un resum: el temps total, el nombre de tasques i el temps mitjà per tasca. Després executa l'script amb 8 tasques i amb aquests valors d'UV_THREADPOOL_SIZE: 1, 2, 4, 8 i 16.

Omple una taula amb els temps totals, explica la forma de la corba i respon: per què passar de 8 a 16 no millora (i probablement empitjora)?

Pista: require('node:os').cpus().length et diu quants nuclis té la teva màquina. La resposta depèn d'aquest número.

Escriu src/laboratori/informe-bloquejant.js que simuli el que passa al servidor d'Escena Viva durant l'obertura de venda d'un festival:

1. Un setInterval cada 50 ms que imprimeixi peticio atesa en T ms (simula els usuaris comprant).
2. Als 500 ms, una funció síncrona calcularOcupacioGlobal() que recorri un array de 3.000 sessions i, per cadascuna, faci un càlcul artificialment costós (per exemple, 200.000 iteracions d'una operació matemàtica) perquè el total trigui al voltant d'un segon.
3. El procés s'ha d'aturar als 3 segons.

Executa'l, compta quantes peticions es van perdre durant el bloqueig i calcula quants usuaris haurien quedat afectats si el servidor atengués 200 peticions per segon.

Escriu src/utils/diagnostic.js, un mòdul de diagnòstic que l'aplicació executarà en arrencar i que imprimeixi per stderr un bloc amb:

• Versió de Node, de V8 i de libuv.
• Plataforma, arquitectura, nombre de nuclis i pid.
• Mida del thread pool efectiva.
• Memòria rss i heapUsed en MB amb un decimal.
• Un avís si la versió major de Node és inferior a 20, amb process.exitCode = 1.
• Un avís si el nombre de nuclis és 1, indicant que cluster no aportarà res (avançament del Mòdul 10).

Ha de funcionar tal qual amb node src/utils/diagnostic.js.

Solució 1

Resultats típics en una màquina de 8 nuclis:

La corba baixa de manera gairebé proporcional fins a igualar el nombre de nuclis i després s'aplana o empitjora. La raó és que aquestes tasques són de CPU pura: amb 8 nuclis només es poden executar 8 càlculs simultanis de debò. Amb 16 fils, el sistema operatiu reparteix els mateixos 8 nuclis entre 16 fils alternant-los, i aquest repartiment té un cost (canvi de context, invalidació de memòria cau) sense cap guany. Més fils només ajuden quan els fils esperen en lloc de calcular, que és el cas de l'E/S de fitxers lenta, no pas el de pbkdf2.

Solució 2

Sortida resumida:

Anàlisi: es van perdre unes 23 ranures de 50 ms. Si el servidor real atengués 200 peticions per segon, un bloqueig d'1,18 segons hauria deixat en espera uns 236 usuaris, tots ells amb la roda girant al navegador encara que la seva compra no tingués res a veure amb l'informe. I no és que s'endarrerissin una mica: es van endarrerir més d'un segon, que en una obertura de venda és la diferència entre aconseguir entrada i no aconseguir-ne.

La solució no és «optimitzar l'informe» (encara que ajudi), sinó treure'l del fil principal: un worker_thread (Mòdul 10) o un treball en cua que el calculi fora i deixi el resultat a la memòria cau.

Solució 3

Detalls de la solució que convé notar:

• Tot per stderr. Així pots fer node src/cataleg.js > cataleg.txt i el diagnòstic es continuarà veient per pantalla sense embrutar el fitxer de dades.
• process.exitCode en lloc de process.exit(), coherent amb la convenció del projecte.
• L'avís d'un sol nucli és real: en un contenidor amb --cpus=1, arrencar 4 processos amb cluster empitjora el rendiment en comptes de millorar-lo.

A la lliçó Mòduls CommonJS i require() convertirem aquest fitxer en un mòdul reutilitzable que exporti la funció diagnosticar en lloc d'executar-la en carregar-se. Ara mateix fa les dues coses, que és justament la mala pràctica que allà aprendrem a evitar.

Has obert la caixa. Node.js no és «JavaScript al servidor» i prou: és un programa en C++ que combina V8, el motor que compila i executa el teu JavaScript amb JIT i gestiona el munt i la recol·lecció d'escombraries, amb libuv, la biblioteca en C que aporta el bucle d'esdeveniments, l'E/S asíncrona del sistema operatiu i un thread pool. Entre tots dos i el teu codi hi ha dues capes més: la biblioteca estàndard —en bona part escrita en JavaScript— i els bindings de C++ que fan de frontera.

Has corregit el tòpic més repetit de l'ecosistema: Node no és d'un sol fil del tot. El teu JavaScript sí que corre en un únic fil —i d'aquí ve la tranquil·litat de no tenir condicions de carrera—, però les lectures de fitxer, les resolucions de dns.lookup, la criptografia i la compressió viatgen a un thread pool de quatre fils configurable amb UV_THREADPOOL_SIZE, mentre que la xarxa fa servir directament epoll, kqueue o IOCP sense consumir fils. I no t'ho has cregut: ho has mesurat amb crypto.pbkdf2, veient com quatre tasques acaben alhora i la cinquena espera el seu torn.

També has comprovat el pecat capital. Un bucle síncron d'un segon va deixar el procés sord durant un segon sencer: sense batecs, sense temporitzadors i —en un servidor real— sense atendre ningú. Aquesta és la raó per la qual a Escena Viva un informe pesat no es pot calcular dins d'una petició, i el motiu que el Mòdul 10 existeixi. Finalment, entens per què un script acaba sol: libuv compta les tasques pendents i, quan el compte arriba a zero, el procés emet exit i mor; un setInterval o un servidor escoltant mantenen aquest compte viu expressament, i unref() és la via d'escapament.

Queda una peça que hem esmentat a cada apartat sense desenvolupar: el bucle d'esdeveniments. Saps que existeix, que gira, que executa callbacks i que compta referències, però no saps en quin ordre fa les coses. I aquest ordre ho explica tot: per què setTimeout(fn, 0) no és immediat, per què setImmediate de vegades va abans que un temporitzador i de vegades després, i per què process.nextTick es cola davant de tothom. A la lliçó següent, El Bucle d'Esdeveniments (Event Loop), recorrerem les seves sis fases una a una fins que puguis predir, línia a línia, l'ordre de sortida de qualsevol programa asíncron.