{"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":"a-mae-voltou-a-bloquear-topicos","status":"publish","type":"post","link":"https:\/\/thecodest.co\/pt\/blog\/mom-he-blocked-threads-again\/","title":{"rendered":"M\u00c3E! Ele bloqueou os t\u00f3picos de novo!"},"content":{"rendered":"

Fios<\/h2>\n

O principal aspeto a ter em conta: existem dois tipos de linhas em Node.js<\/a><\/strong>: Main Thread - que \u00e9 gerido por Ciclo de eventos<\/b>e Pool de trabalhadores<\/b> (pool de threads) - que \u00e9 o pool de threads -
\ngra\u00e7as \u00e0 libuv<\/a>. Cada um deles tem uma fun\u00e7\u00e3o diferente. O objetivo do primeiro \u00e9 lidar com opera\u00e7\u00f5es de E\/S n\u00e3o bloqueantes, e o segundo \u00e9 respons\u00e1vel pelo trabalho intensivo da CPU e tamb\u00e9m pelo bloqueio de E\/S.<\/p>\n

\"diagrama<\/p>\n

Mas o que \u00e9 uma linha e em que \u00e9 que \u00e9 diferente de um processo? Existem v\u00e1rias diferen\u00e7as, mas a mais importante para n\u00f3s<\/a> \u00e9 a forma como a mem\u00f3ria lhes \u00e9 atribu\u00edda. Pode pensar num processo como se fosse uma aplica\u00e7\u00e3o. Dentro de cada processo, h\u00e1 um peda\u00e7o de mem\u00f3ria dedicado apenas a esse processo. Assim, um processo n\u00e3o tem acesso \u00e0 mem\u00f3ria do segundo, e essa propriedade garante alta seguran\u00e7a. Para estabelecer a comunica\u00e7\u00e3o entre eles, temos que fazer algum trabalho. Threads s\u00e3o diferentes. As threads correm dentro de um processo e partilham a mesma mem\u00f3ria, pelo que n\u00e3o h\u00e1 qualquer problema com a partilha de threads dados<\/a>.<\/p>\n

No entanto, h\u00e1 uma quest\u00e3o que causa um problema. \u00c9 a chamada condi\u00e7\u00e3o de corrida. As threads podem ser executadas ao mesmo tempo, por isso como \u00e9 que sabemos qual termina primeiro? Pode acontecer que, na primeira vez que a executamos, a primeira opera\u00e7\u00e3o termine primeiro e, na vez seguinte, pode acontecer o contr\u00e1rio e a segunda opera\u00e7\u00e3o terminar antes da primeira. Imagine trabalhar com opera\u00e7\u00f5es de escrita\/leitura nestas condi\u00e7\u00f5es! Um pesadelo! Por vezes \u00e9 muito dif\u00edcil escrever corretamente c\u00f3digo<\/a> num ambiente multi-threaded.<\/p>\n

Al\u00e9m disso, as linguagens multithread t\u00eam uma grande sobrecarga de mem\u00f3ria porque criam um thread separado para cada pedido; assim, se quiser chamar 1000 pedidos, criam 1000 threads.<\/p>\n

Como lidar com este problema? Utilizar um \u00fanico fio! E \u00e9 isso que N\u00f3<\/a><\/strong> oferece-lhe.<\/p>\n

\"ciclo<\/p>\n

Como Desenvolvedor JavaScript<\/a><\/strong> Encorajo-vos a ver o filme<\/a>
\nem que Bart Belder explica claramente o conceito de ciclo de eventos. O diagrama acima foi retirado da sua apresenta\u00e7\u00e3o. E se n\u00e3o conhece estes termos, ambos N\u00f3<\/strong> e a Libuv tem uma excelente documenta\u00e7\u00e3o \ud83d\ude42<\/p>\n

Sobre o bloqueio<\/h2>\n

Em JavaScript<\/a> desenvolvimento<\/strong> ind\u00fastria dizem que porque N\u00f3<\/strong> \u00e9 single-threaded e n\u00e3o-bloqueante, \u00e9 poss\u00edvel obter uma maior simultaneidade com os mesmos recursos do que com solu\u00e7\u00f5es multi-threaded. \u00c9 verdade, mas n\u00e3o \u00e9 t\u00e3o bonito e f\u00e1cil como pode parecer.<\/p>\n

Desde Node.js<\/strong> \u00e9 de thread \u00fanico (JS<\/a> parte), as tarefas com uso intensivo de CPU bloquear\u00e3o todos os pedidos em curso at\u00e9 que a tarefa em causa esteja conclu\u00edda. Ent\u00e3o, \u00e9 verdade que em Node.js<\/strong> pode bloquear todos os pedidos s\u00f3 porque um deles tinha uma instru\u00e7\u00e3o de bloqueio no seu interior. O c\u00f3digo de bloqueio significa que demora mais do que alguns milissegundos a terminar. Mas n\u00e3o confunda tempo de resposta longo com bloqueio. A resposta da base de dados pode demorar muito tempo, mas n\u00e3o bloqueia o seu processo (aplica\u00e7\u00e3o).<\/p>\n

Os m\u00e9todos bloqueantes s\u00e3o executados de forma s\u00edncrona e os m\u00e9todos n\u00e3o bloqueantes s\u00e3o executados de forma ass\u00edncrona.<\/p>\n

Como \u00e9 que pode abrandar (ou bloquear) o seu ciclo de eventos?<\/p>\n