Der Event-Loop führt dein JavaScript in einem einzigen Thread (single thread) aus, daher blockiert alles Synchrone, das lange dauert, ihn — und solange er blockiert ist, bedient Node keinen weiteren Request, Timer oder Callback. Blockieren ist fast immer CPU-gebundene Arbeit (CPU-bound) oder ein *Sync-API, niemals korrekt awaitetes asynchrones I/O.
*Sync) APIs — fs.readFileSync, fs.writeFileSync, child_process.execSync, zlib.gzipSync. Sie warten inline, statt die Arbeit an libuv zu übergeben.map/sort/filter, Matrixmathematik, Bild-/Videoverarbeitung, Parsen/Serialisieren riesiger Strukturen.JSON.parse / JSON.stringify — synchron und O(n); ein Payload von mehreren MB friert den Loop für das gesamte Parsen ein.crypto.pbkdf2Sync, bcrypt im Sync-Modus, Hashing großer Buffer im Haupt-Thread.while (true), unbegrenzte Rekursion, for über Millionen von Elementen mit Arbeit pro Element.// All dies blockiert den Loop — währenddessen wird kein anderer Request bedient:
const data = fs.readFileSync("big.json"); // synchrones I/O
const obj = JSON.parse(hugeString); // großes Parsen
const hash = crypto.pbkdf2Sync(pw, salt, 1e6, 64, "sha512"); // synchrone Kryptografie
for (let i = 0; i < 1e9; i++) { /* CPU */ } // enge Schleife
CPU-Arbeit in eine
async-Funktion zu verpacken hilft nicht —asyncgibt die Kontrolle nur beiawaitab; der synchrone Rumpf läuft trotzdem im Loop-Thread bis zum Ende durch.
perf_hooks.monitorEventLoopDelay() oder Bibliotheken wie blocked-at; steigende Verzögerung bedeutet, dass etwas den Thread belegt.node --prof, clinic doctor/clinic flame, CPU-Profil in den Chrome DevTools, um den heißen synchronen Frame zu finden.*Sync-Aufrufs (fs.promises.readFile, crypto.pbkdf2, zlib.gzip).worker_threads-Pool, einen Child-Prozess oder eine externe Queue/einen externen Service.setImmediate/await, damit der Loop zwischen den Batches durchatmen kann.const { Worker } = require("node:worker_threads");
// Lagere das teure Hashing aus, damit der Loop reaktionsfähig bleibt.
const worker = new Worker("./hash-worker.js", { workerData: { pw, salt } });
In Node bestraft ein einziger blockierender Aufruf jeden gleichzeitigen Client, nicht nur den Request, der ihn verursacht hat — die Latenz schießt in die Höhe, Health Checks laufen ab, und der Prozess wirkt unter Last „aufgehängt". Interviewer fragen das, um zu sehen, ob du die konkreten Blocker benennen (*Sync, große JSON.parse, synchrone Kryptografie, ReDoS, CPU-Schleifen), sie mit Tools zur Event-Loop-Verzögerung erkennen und durch den Wechsel zu async oder das Auslagern in Worker Threads beheben kannst. Es ist das mit Abstand häufigste Node-Performance-Problem in der Produktion.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden