Gründe für die Verwendung asynchroner APIs
Der Grund, warum das Konzept von Asynchron in Web2.0 populär wurde, ist, dass JavaScript in einem einzigen Thread im Browser ausgeführt wird und auch einen Thread mit UI -Rendering verwendet. Dies bedeutet, dass UI -Rendering und Antworten in einem stagnierenden Zustand liegen, wenn JavaScript ausgeführt wird. Für eine bessere Benutzererfahrung blockiert ein asynchroner Ansatz (natürlich ist dies in der sogenannten Sprache mit einem Threaden) den Haupt-Thread nicht und reagiert weiterhin auf Benutzeroperationen. Dies gehört zur Kategorie der Benutzererfahrung.
Wenn Ingenieure mit Erfahrung in anderen Sprachen natürlich verstehen, dass die CPU -Wechsel zwischen Threads viel Zeit erfordert (hauptsächlich zwischen Kontexten und Zwischenspeichern), ist die Verbesserung der Effizienz auch ein Grund, asynchrone APIs zu verwenden.
Natürlich sind diese nicht absolut korrekt, aber jeder sagt es. Denn wenn der Overhead der Erstellung von Multithreads weniger als parallele Ausführung ist, ist die Methode des Multithreading die erste Wahl, die häufig als CPU-intensive Verarbeitungsaufgabe angesehen wird.
Kurz gesagt, asynchrones IO- oder Asynchron -API kann als Merkmal des Knotens angesehen werden, da es sich um eine Plattform handelt, die asynchrones IO auf der Anwendungsschicht in großem Maßstab anwendet, und es ist bestrebt, Ressourcen effizienter auf einem einzelnen Faden zuzuweisen.
Über Versprechen
Hier beabsichtigt dieser Artikel nicht, die Verwendung von Versprechen im Detail zu erklären, sondern erklärt nur kurz einige der APIs und der Versuchsumfang des Versprechens:
// Kombinieren von NodeJS 'fs.Readdir -Funktion zum Erstellen einer nativen PromiseVar Promisetask = New Promise (Funktion (Resolve, Ablehnung) {fs console.log ('Inhalt ist:'+Dateien); promisetask.catch (Funktion (err) {console.log ('Der Fehler wird als:'+err);});Wie warte ich, bis mehrere Versprechen abgeschlossen sind?
// Verbinde die obige Promisetask.then (Funktion (Dateien) {var readFilsePromiselist = files.map (Funktion (Datei, Index) {Neue Versprechen zurückgeben (Funktion (Auflösung, ablehnen) {fs Versprach.All (ReadFilsePromiselist);}). Dann (Funktion (filestray) {console.log ('sogenannte Datei-Lesung abgeschlossen:'+filestray);});Dieser Code zeigt die Eleganz der NodeJS -Entwicklung.
Was ist das Problem?
Die eleganteste Sprache stützt sich derzeit immer noch auf das Betriebssystem, dh die Systembeschränkungen bestehen immer noch:
Ich weiß nicht, ob dieser Fehler als erschöpfte Dateioperation interpretiert werden kann, aber ich hoffe, Sie können diesen Artikel verstehen, dass das Betriebssystem nicht gleichzeitig unbegrenzt mehrere Dateien öffnen kann.
Und das:
Dies ist leicht zu verstehen und die Erinnerung ist erschöpft. Natürlich kann das Speichergrenze eingestellt werden, indem die folgenden zwei laufenden Parameter hinzugefügt werden:
Knoten-Max-alte Space-Größe = 8192 ./index.js #Unit MB Knoten ---maxnew-space-Größe = 2048 ./index.js #Unit KB
Die oben genannten Parameter wirksam, wenn der V8 initialisiert wird und nicht dynamisch geändert werden kann, wenn sie wirksam werden.
Viele Menschen mögen vorschlagen, dass diese beiden Einschränkungen auch in anderen Sprachen existieren. Ja, auch andere Sprachen existieren.
Durch leistungsstarke GC- oder Multithread -Programmiermodelle in anderen Sprachen können Ingenieure sie rechtzeitig freigeben, nachdem sie die Systemressourcen beantragt haben.
Obwohl unnötige Systemressourcen manuell in NodeJs freigegeben werden können, kann jeder Betrieb im Referenzprogramm rechtzeitig freigegeben werden?
Beispielsweise liefert das NodeJS REDIS -Paket (NPM Install -Redis) keine Synchronisierungsbetriebsmethoden.
Dies bedeutet, dass im Entwicklungsprozess mehr Prozesskontrolle erforderlich ist. Leider ist NodeJs in einem einzel-betrügerischen System nicht gut darin, da es kein Konzept des Multi-Threading gibt, keinen Verriegelungsmechanismus, und es ist unmöglich, Semaphor-Mechanismen in den üblichen Sinne aufzunehmen. Das Ergebnis ist, dass Ingenieure nicht wissen, wann sie Ressourcen manuell freigeben sollen.
Wenn Sie nicht die absolute Kontrolle über Ihr Projekt haben, verwenden Sie keine Pakete von Drittanbietern, die asynchrone APIs verwenden.
Die derzeitige Schlussfolgerung ist daher, dass Versprechen nur eine Entwicklungstechnik ist. Das Verständnis dieser ist für alle Entwicklungsszenarien nicht geeignet.
Zusammenfassen
Das obige dreht sich alles um die asynchrone API von Node.js und seine Grenzen. Ich hoffe, dieser Artikel wird für alle hilfreich sein. Wenn Sie Fragen haben, überlassen Sie bitte eine Nachricht, um zu kommunizieren.