Implementieren Sie die Blockierungsinstanz in nodejs_node.js

Der in node.js inhärente asynchrone Stil der Single-Thread-Programmierung und Rückruffunktion macht uns manchmal glücklich und manchmal besorgt. Lassen Sie uns zunächst über Single-Threading sprechen. Viele Leute fragen sich, wie der Single-Thread von node.js eine hohe Parallelität erreichen kann. Dieses Problem steht nicht im Mittelpunkt dieses Artikels, also lassen Sie uns hier aufhören. Zur Verdeutlichung: Der einzelne Thread von node.js bezieht sich nur auf die Single-Threaded-JavaScript-Engine. Wir haben jedoch keine Möglichkeit, Multithreading und Blockierung in JavaScript zu implementieren (die in diesem Artikel verwendete Methode wird auch nicht durch synchronisiert). V8-Engine), aber für Knoten. Andere Aspekte von .js bedeuten nicht, dass es nicht multithreadbar ist, wie z. B. IO. Wenn node.js nun einer großen Anzahl von Anforderungen ausgesetzt ist und diese Anforderungen E/A-intensiv sind, wartet der Javascript-Thread nicht immer hier, wenn er auf eine lange E/A-Operation stößt, sondern übergibt die Kontrolle und Fügen Sie die Operationen hinzu, die nach Abschluss der E/A-Operation im Rückrufstapel ausgeführt werden sollen (wenn zu viele Rückrufebenen vorhanden sind und die Anzahl der Zugriffe zu groß ist, kann eine große Anzahl von Rückrufketten den Stapel platzen lassen). Während dieser Zeit kann node.js andere Anfragen bearbeiten. Obwohl Javascript Single-Threaded ist und jeweils nur eine Anfrage verarbeiten kann, ist die Zeit, die Javascript für die Verarbeitung einer Anfrage benötigt, oft kürzer (für IO-intensive Anwendungen, solange es verarbeitet werden kann). asynchron, dann während der Verarbeitung gibt diese Anforderung die Kontrolle frei, sodass node.js andere Anforderungen verarbeiten kann. Während dieser gleichzeitigen Anforderung befindet sich E/A tatsächlich immer in einem gleichzeitigen Zustand, wodurch die Anzahl der Threads, die Anforderungen verarbeiten, reduziert und Ressourcen gespart werden, um die Anzahl der E/A-Threads zu erhöhen, die normalerweise lange dauern, was zweifellos zu Leistungsverbesserungen führt . fördern.

Ich habe in der Vergangenheit die IO-Intensität betont, aber eigentlich betone ich die Stärken von node.js. Dementsprechend besteht sein Manko in CPU-intensiven Anfragen. Der Grund ist sehr einfach: JavaScript ist nicht gleichzeitig und andere Anforderungen können erst verarbeitet werden, nachdem eine Anforderung abgeschlossen ist. Je länger die Bearbeitung einer Anfrage dauert, desto länger müssen andere Anfragen warten. Es wird jeweils nur eine Anfrage verarbeitet und die Parallelitätsleistung ist sehr gering.

Allerdings möchte ich klarstellen: node.js sollte nicht blockiert werden; Methoden, die asynchron verarbeitet werden können, werden asynchron verarbeitet (z. B. die Verwendung von fs.readFile() anstelle von fs.syncReadFile() fs.readFileSync ()-Methode).

Kann im Knoten nicht blockiert werden. Dies bedeutet nicht, dass es nicht außerhalb des Knotens blockiert werden kann. Wir haben vorhin über Fasern gesprochen. Versuchen wir nun, die Blockierung in Fasern umzusetzen. Nehmen wir als Beispiel die Verarbeitung einer http-Anfrage:

Code kopieren Der Code lautet wie folgt:

var Fiber = require('fibers');
var http = require("http");
Fiber(function () {
var httpFiber = Fiber.current;
var html = "";
http.get("http://www.baidu.com", Funktion (res) {
        var dataFiber = Fiber.current;
res.on("data", function (data) {
               html = data;
        });
          res.on("end", Funktion (Daten) {
httpFiber.run();
        });
});
Fiber.yield();
console.log(html);
}).run();

Für Schüler, die mit den Methoden

yield() und run() nicht vertraut sind, überprüfen Sie bitte selbst „Fasern im Knoten“.

Fasern laufen nicht im Knotenprozess, daher hat das Blockieren innerhalb von Fasern keinen Einfluss auf die Gesamtleistung des Knotens. Und es ist ganz einfach umzusetzen. Sie müssen die Faser nur dann nachgeben, wenn Sie blockieren möchten. Wenn Sie die Ausführung fortsetzen müssen, führen Sie run() aus, um die Fiber wiederherzustellen. Im obigen Beispiel möchten wir das aktuelle Programm blockieren, wenn die http.get-Anfrage initiiert wird, und das Programm fortsetzen, wenn der gesamte Datenempfang abgeschlossen ist. Daher verwenden wir Fiber.yield(), um diese Faser nach dem Aufruf von http.get zu unterbrechen. Wenn bei der Überwachung der Antwort das Endereignis ausgelöst wird, bedeutet dies, dass die Datenübertragung abgeschlossen ist. Rufen Sie daher in der End-Callback-Funktion Fiber.current.run() auf, um die Fiber wiederherzustellen. Auf diese Weise wird der nachfolgende Code abgerufen http.get auf synchrone Weise.

Das obige Beispiel dient nur zur Veranschaulichung. Wenn Sie diese Idee abstrakt kapseln, führen Sie beispielsweise ein einstufiges Currying für eine asynchrone Methode durch, die eine Rückruffunktion als Parameter akzeptiert, unterbrechen Sie sie nach dem Aufruf und kapern Sie die Rückruffunktion, um den Programmcode als Rückruf wiederherzustellen Funktion. Nach Erhalt der asynchronen Daten löst das Programm die vorgegebene Rückruffunktion aus, mit der grundsätzlich die Synchronisation der asynchronen Methode realisiert werden kann. Dieser Absatz ist ziemlich verwirrend, aber im Grunde handelt es sich um die Implementierungsidee von Fibers/Future. Wenn Sie interessiert sind, lesen Sie bitte den Quellcode.