{"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":"mama-volvio-a-bloquear-hilos","status":"publish","type":"post","link":"https:\/\/thecodest.co\/es\/blog\/mom-he-blocked-threads-again\/","title":{"rendered":"\u00a1MAM\u00c1! \u00a1Ha vuelto a bloquear hilos!"},"content":{"rendered":"

Hilos<\/h2>\n

Lo principal a recordar: hay dos tipos de hilos en Node.js<\/a><\/strong>: Main Thread - que es manejado por Bucle de eventos<\/b>y Pool de trabajadores<\/b> (pool de hilos) - que es el pool de hilos -
\ngracias a libuv<\/a>. Cada uno de ellos tiene un trabajo diferente. El objetivo del primero es gestionar las operaciones de E\/S no bloqueantes, y el segundo es responsable del trabajo intensivo de la CPU y tambi\u00e9n de las E\/S bloqueantes.<\/p>\n

\"diagrama<\/p>\n

Pero, \u00bfqu\u00e9 es un hilo y en qu\u00e9 se diferencia de un proceso? Hay varias diferencias, pero la m\u00e1s importante para us<\/a> es c\u00f3mo se les asigna la memoria. Puedes pensar en un proceso como en una aplicaci\u00f3n. Dentro de cada proceso, hay un trozo de memoria dedicado s\u00f3lo para este proceso. As\u00ed, un proceso no tiene acceso a la memoria del segundo, y esta propiedad garantiza una alta seguridad. Para establecer comunicaci\u00f3n entre ellos, debemos hacer alg\u00fan trabajo. Los hilos son diferentes. Los hilos se ejecutan dentro de un proceso y comparten la misma memoria, por lo que no hay ning\u00fan problema en que los hilos compartan memoria. datos<\/a>.<\/p>\n

Sin embargo, hay una cuesti\u00f3n que causa problemas. Se llama condici\u00f3n de carrera. Los hilos pueden ejecutarse al mismo tiempo, as\u00ed que \u00bfc\u00f3mo sabemos cu\u00e1l termina primero? Puede ocurrir que la primera vez que lo ejecutes, la primera operaci\u00f3n termine primero, y la pr\u00f3xima vez puede resultar lo contrario y la segunda operaci\u00f3n termine antes que la primera. \u00a1Imag\u00ednate trabajar con operaciones de escritura\/lectura en esas condiciones! \u00a1Una pesadilla! A veces es muy dif\u00edcil escribir correctamente c\u00f3digo<\/a> en un entorno multihilo.<\/p>\n

Adem\u00e1s, los lenguajes multihilo tienen una gran sobrecarga de memoria porque crean un hilo distinto para cada petici\u00f3n; as\u00ed, si quieres llamar a 1000 peticiones, crean 1000 hilos.<\/p>\n

\u00bfC\u00f3mo solucionar este problema? Utilizando un \u00fanico hilo. Y eso es lo que Nodo<\/a><\/strong> te ofrece.<\/p>\n

\"bucle<\/p>\n

Como Promotor JavaScript<\/a><\/strong> Le animo a que vea el pel\u00edcula<\/a>
\nen la que Bart Belder explica claramente el concepto de bucle de eventos. El diagrama anterior est\u00e1 tomado de su presentaci\u00f3n. Y si no conoce estos t\u00e9rminos en absoluto, tanto Nodo<\/strong> y Libuv tienen una documentaci\u00f3n excelente \ud83d\ude42 .<\/p>\n

Acerca del bloqueo<\/h2>\n

En JavaScript<\/a> desarrollo<\/strong> industria dicen que porque Nodo<\/strong> es monohilo y no bloqueante, se puede lograr una mayor concurrencia con los mismos recursos que con las soluciones multihilo. Es cierto, pero no es tan bonito y f\u00e1cil como parece.<\/p>\n

Desde Node.js<\/strong> es monohilo (JS<\/a> parte), las tareas de uso intensivo de CPU bloquear\u00e1n todas las peticiones en curso hasta que se complete la tarea concreta. Por lo tanto, es cierto que en Node.js<\/strong> puedes bloquear todas las peticiones s\u00f3lo porque una de ellas conten\u00eda una instrucci\u00f3n de bloqueo. El c\u00f3digo bloqueante significa que tarda m\u00e1s de unos milisegundos en terminar. Pero no confunda un tiempo de respuesta largo con bloqueo. La respuesta de la base de datos puede tomar mucho tiempo, pero no bloquea su proceso (aplicaci\u00f3n).<\/p>\n

Los m\u00e9todos bloqueantes se ejecutan de forma sincr\u00f3nica y los no bloqueantes de forma asincr\u00f3nica.<\/p>\n

\u00bfC\u00f3mo puedes ralentizar (o bloquear) tu bucle de eventos?<\/p>\n