{"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-han-blokkerte-trader-igjen","status":"publish","type":"post","link":"https:\/\/thecodest.co\/nb\/blog\/mom-he-blocked-threads-again\/","title":{"rendered":"MAMMA! Han blokkerte tr\u00e5der igjen!"},"content":{"rendered":"

Tr\u00e5der<\/h2>\n

Det viktigste \u00e5 huske: Det finnes to typer tr\u00e5der i Node.js<\/a><\/strong>: Main Thread - som h\u00e5ndteres av Hendelsessl\u00f8yfe<\/b>, og Arbeidstakerpool<\/b> (tr\u00e5dpool) - som er en pool av tr\u00e5der - og
\ntakket v\u00e6re libuv<\/a>. Hver av dem har forskjellige oppgaver. Den f\u00f8rste har som m\u00e5l \u00e5 h\u00e5ndtere ikke-blokkerende I\/O-operasjoner, mens den andre er ansvarlig for CPU-intensivt arbeid og blokkerende I\/O.<\/p>\n

\"diagram<\/p>\n

Men hva er en tr\u00e5d, og hvordan skiller den seg fra en prosess? Det er flere forskjeller, men den viktigste for oss<\/a> er hvordan minnet allokeres til dem. Du kan tenke p\u00e5 en prosess som p\u00e5 et program. Inne i hver prosess er det en del av minnet som er dedikert bare til denne prosessen. Den ene prosessen har alts\u00e5 ikke tilgang til minnet til den andre, og denne egenskapen s\u00f8rger for h\u00f8y sikkerhet. For \u00e5 etablere kommunikasjon mellom dem, m\u00e5 vi gj\u00f8re noe arbeid. Tr\u00e5der er annerledes. Tr\u00e5der kj\u00f8rer inne i en prosess og deler det samme minnet, s\u00e5 det er ikke noe problem i det hele tatt med tr\u00e5der som deler data<\/a>.<\/p>\n

Det er imidlertid \u00e9n ting som skaper problemer. Det kalles \"race condition\". Tr\u00e5dene kan kj\u00f8re samtidig, s\u00e5 hvordan vet vi hvilken som avsluttes f\u00f8rst? Det kan hende at f\u00f8rste gang du kj\u00f8rer den, slutter den f\u00f8rste operasjonen f\u00f8rst, og neste gang kan det vise seg \u00e5 v\u00e6re motsatt, og den andre operasjonen slutter f\u00f8r den f\u00f8rste. Tenk deg \u00e5 jobbe med skrive-\/leseoperasjoner under slike forhold! Et mareritt! Det er noen ganger veldig vanskelig \u00e5 skrive korrekt kode<\/a> i et flertr\u00e5det milj\u00f8.<\/p>\n

De flertr\u00e5dede spr\u00e5kene har ogs\u00e5 et stort minneoverhead fordi de oppretter en egen tr\u00e5d for hver foresp\u00f8rsel, s\u00e5 hvis du vil ringe 1000 foresp\u00f8rsler, oppretter de 1000 tr\u00e5der.<\/p>\n

Hvordan h\u00e5ndtere et slikt problem? Bruk en enkelt tr\u00e5d i stedet! Og det er det som Knutepunkt<\/a><\/strong> tilbyr deg.<\/p>\n

\"enkelttr\u00e5d<\/p>\n

Som en JavaScript utvikler<\/a><\/strong> Jeg oppfordrer deg til \u00e5 se film<\/a>
\nder Bart Belder tydelig forklarer konseptet med hendelsessl\u00f8yfen. Diagrammet ovenfor er hentet fra presentasjonen hans. Og hvis du ikke kjenner disse begrepene i det hele tatt, b\u00e5de Knutepunkt<\/strong> og Libuv har utmerket dokumentasjon \ud83d\ude42 .<\/p>\n

Om blokkering<\/h2>\n

I JavaScript<\/a> utvikling<\/strong> industrien sier de at fordi Knutepunkt<\/strong> er enkelttr\u00e5det og ikke-blokkerende, kan du oppn\u00e5 h\u00f8yere samtidighet med de samme ressursene enn med flertr\u00e5dede l\u00f8sninger. Det er sant, men det er ikke s\u00e5 vakkert og enkelt som det kan virke.<\/p>\n

Siden Node.js<\/strong> er enkelttr\u00e5det (JS<\/a> del), vil CPU-intensive oppgaver blokkere alle foresp\u00f8rsler som p\u00e5g\u00e5r til den aktuelle oppgaven er fullf\u00f8rt. S\u00e5 det er sant at i Node.js<\/strong> kan du blokkere alle foresp\u00f8rsler bare fordi en av dem inneholdt en blokkerende instruksjon. Blokkerende kode betyr at det tar mer enn noen f\u00e5 millisekunder \u00e5 fullf\u00f8re. Men ikke forveksle lang responstid med blokkering. Svaret fra databasen kan ta sv\u00e6rt lang tid, men det blokkerer ikke prosessen (applikasjonen).<\/p>\n

Blokkerende metoder utf\u00f8res synkront, mens ikke-blokkerende metoder utf\u00f8res asynkront.<\/p>\n

Hvordan kan du bremse (eller blokkere) hendelsessl\u00f8yfen din?<\/p>\n