Der Inhalt dieses Artikels befasst sich mit der Erklärung des Blockierens und Nichtblockierens in Node.js. Ich hoffe, dass er für Freunde hilfreich ist.
Blockierende vs. nicht blockierende Übersicht
Diese Übersicht erklärt den Unterschied zwischen blockierenden und nicht blockierenden Aufrufen in Node.js. Diese Übersicht bezieht sich auf die Ereignisschleife und libuv. Es sind keine Vorkenntnisse zu diesen Themen erforderlich, es wird jedoch ein grundlegendes Verständnis der JavaScript-Sprache und der Node.js-Rückrufmuster vorausgesetzt.
„E/A“ bezieht sich hauptsächlich auf die Interaktion mit der Festplatte und dem Netzwerk des von libuv unterstützten Systems.
Blockieren bedeutet, dass die Ausführung von anderem JavaScript im Node.js-Prozess warten muss, bis der Nicht-JavaScript-Vorgang abgeschlossen ist. Dies geschieht, weil die Ereignisschleife während des Blockierungsvorgangs nicht mit der Ausführung von JavaScript fortfahren kann auftritt.
In Node.js wird JavaScript, das eine schlechte Leistung aufweist, weil es CPU-intensiv ist und nicht auf Nicht-JavaScript-Vorgänge wie E/A wartet, im Allgemeinen nicht als Blockierung bezeichnet. Die Synchronisierungsmethode mit libuv in der Node.js-Standardbibliothek ist die am häufigsten verwendete Blockierungsoperation, und native Module verfügen möglicherweise auch über Blockierungsmethoden.
Alle I/O-Methoden in der Node.js-Standardbibliothek stellen nicht blockierende asynchrone Versionen bereit und akzeptieren Rückruffunktionen. Einige Methoden verfügen auch über entsprechende blockierende Methoden, deren Namen mit Sync enden.
Blockierende Methoden werden synchron ausgeführt und nicht blockierende Methoden werden asynchron ausgeführt.
Nehmen Sie das Dateisystemmodul als Beispiel. Hier ist eine Methode zum synchronen Lesen einer Datei:
const fs = require('fs');
const data = fs.readFileSync('/file.md'); // blocks here until file is readHier ist ein entsprechendes asynchrones Beispiel:
const fs = require('fs');
fs.readFile('/file.md', (err, data) => {
if (err) throw err;
});Erstes Beispiel Sieht einfacher aus als das zweite Beispiel, aber der Nachteil ist, dass die zweite Zeile die Ausführung von anderem JavaScript verhindert, bis die gesamte Datei gelesen ist. Beachten Sie, dass Sie in der synchronen Version einen Fehler abfangen müssen, wenn er geworfen wird, andernfalls wird der Prozess ausgeführt crash: In der asynchronen Version ist es dem Autor überlassen, ob wie gezeigt ein Fehler ausgegeben werden soll.
Erweitern wir unser Beispiel ein wenig:
const fs = require('fs');
const data = fs.readFileSync('/file.md'); // blocks here until file is read
console.log(data);
// moreWork(); will run after console.logHier ist ein ähnliches, aber nicht äquivalentes asynchrones Beispiel:
const fs = require('fs');
fs.readFile('/file.md', (err, data) => {
if (err) throw err;
console.log(data);
});
// moreWork(); will run before console.log Im ersten Beispiel oben würden wir moreWork() heißen Vor console.log ist fs.readFile() im zweiten Beispiel nicht blockierend, sodass die JavaScript-Ausführung fortgesetzt werden kann und moreWork() zuerst aufgerufen wird und ist ein Schlüssel Designauswahl, die den Durchsatz verbessern kann. moreWork()
const fs = require('fs');
fs.readFile('/file.md', (err, data) => {
if (err) throw err;
console.log(data);
});
fs.unlinkSync('/file.md');const fs = require('fs');
fs.readFile('/file.md', (readFileErr, data) => {
if (readFileErr) throw readFileErr;
console.log(data);
fs.unlink('/file.md', (unlinkErr) => {
if (unlinkErr) throw unlinkErr;
});
});Das obige ist der detaillierte Inhalt vonEine Erklärung zum Blockieren und Nichtblockieren in Node.js. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
