{"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":"mor-han-blokerede-trade-igen","status":"publish","type":"post","link":"https:\/\/thecodest.co\/da\/blog\/mom-he-blocked-threads-again\/","title":{"rendered":"MOM! Han har blokeret tr\u00e5de igen!"},"content":{"rendered":"

Tr\u00e5de<\/h2>\n

Det vigtigste at huske: Der er to typer tr\u00e5de i Node.js<\/a><\/strong>: Hovedtr\u00e5d - som h\u00e5ndteres af Begivenheds-loop<\/b>og Arbejderpulje<\/b> (tr\u00e5dpulje) - som er puljen af tr\u00e5de -.
\ntakket v\u00e6re libuv<\/a>. Hver af dem har et forskelligt job. M\u00e5let for den f\u00f8rste er at h\u00e5ndtere ikke-blokerende I\/O-operationer, og den anden er ansvarlig for CPU-intensivt arbejde og ogs\u00e5 blokerende I\/O.<\/p>\n

\"diagram<\/p>\n

Men hvad er en tr\u00e5d, og hvordan adskiller den sig fra en proces? Der er flere forskelle, men den vigtigste for os<\/a> er, hvordan hukommelsen allokeres til dem. Du kan t\u00e6nke p\u00e5 en proces som p\u00e5 et program. I hver proces er der en del af hukommelsen, som kun er dedikeret til denne proces. S\u00e5 den ene proces har ikke adgang til den andens hukommelse, og denne egenskab sikrer h\u00f8j sikkerhed. For at etablere kommunikation mellem dem skal vi udf\u00f8re noget arbejde. Tr\u00e5de er anderledes. Tr\u00e5de k\u00f8rer inde i en proces og deler den samme hukommelse, s\u00e5 der er slet ikke noget problem med, at tr\u00e5de deler data<\/a>.<\/p>\n

Men \u00e9n ting skaber problemer. Det kaldes race condition. Tr\u00e5dene kan k\u00f8re p\u00e5 samme tid, s\u00e5 hvordan ved vi, hvilken der slutter f\u00f8rst? Det kan ske, at den f\u00f8rste gang du k\u00f8rer den, slutter den f\u00f8rste operation f\u00f8rst, og n\u00e6ste gang kan det vise sig at v\u00e6re det modsatte, og den anden operation slutter f\u00f8r den f\u00f8rste. Forestil dig at arbejde med skrive-\/l\u00e6seoperationer under s\u00e5danne forhold! Et mareridt! Det er nogle gange meget sv\u00e6rt at skrive korrekte Kode<\/a> i et multi-threaded milj\u00f8.<\/p>\n

De flertr\u00e5dede sprog har ogs\u00e5 et stort hukommelsesoverhead, fordi de opretter en separat tr\u00e5d for hver anmodning; s\u00e5 hvis du vil kalde 1000 anmodninger, opretter de 1000 tr\u00e5de.<\/p>\n

Hvordan h\u00e5ndterer man s\u00e5dan et problem? Brug en enkelt tr\u00e5d i stedet! Og det er, hvad Knudepunkt<\/a><\/strong> tilbyder dig.<\/p>\n

\"enkelt<\/p>\n

Som en JavaScript udvikler<\/a><\/strong> Jeg opfordrer dig til at se film<\/a>
\nhvor Bart Belder tydeligt forklarer begrebet event loop. Ovenst\u00e5ende diagram er taget fra hans pr\u00e6sentation. Og hvis du slet ikke kender disse begreber, kan b\u00e5de Knudepunkt<\/strong> og Libuv har fremragende dokumentation \ud83d\ude42.<\/p>\n

Om blokering<\/h2>\n

I JavaScript<\/a> udvikling<\/strong> industrien siger de, at fordi Knudepunkt<\/strong> er enkelttr\u00e5det og ikke-blokerende, kan du opn\u00e5 h\u00f8jere samtidighed med de samme ressourcer end med flertr\u00e5dede l\u00f8sninger. Det er sandt, men det er ikke s\u00e5 smukt og nemt, som det m\u00e5ske ser ud til.<\/p>\n

Siden Node.js<\/strong> er enkelttr\u00e5det (JS<\/a> del), vil CPU-intensive opgaver blokere alle igangv\u00e6rende anmodninger, indtil den p\u00e5g\u00e6ldende opgave er afsluttet. S\u00e5 det er rigtigt, at i Node.js<\/strong> kan man blokere alle foresp\u00f8rgsler, bare fordi en af dem indeholder en blokerende instruktion. Den blokerende kode betyder, at det tager mere end et par millisekunder at afslutte. Men forveksl ikke lang svartid med blokering. Svaret fra databasen kan tage meget lang tid, men det blokerer ikke din proces (applikation).<\/p>\n

Blokerende metoder udf\u00f8res synkront, og ikke-blokerende metoder udf\u00f8res asynkront.<\/p>\n

Hvordan kan du g\u00f8re dit event-loop langsommere (eller blokere det)?<\/p>\n