Sta dicendo "non ci sono thread in nodejs" corretto?

Confronto tra Node.js a Java è un po 'come paragonare le mele alle arance e più come confrontare un dizionario con un libro di testo di grammatica (grazie scriptin ).

Node.js è un quasi-quadro scritto in JavaScript utilizzando il motore JavaScript V8 di Google per creare il codice JavaScript nel codice macchina nativo che può essere utilizzato lato server (invece di interpretare il codice JS in tempo reale).

Java è un linguaggio (non un framework) a cui un'implementazione del JDK (cioè Oracle JDK e OpenJDK) possono vedere come implementare i costrutti del linguaggio sottostante (thread, I / O, ecc.).

Node.js non ha un modello di threading, cioè non puoi generare un thread direttamente attraverso l'API Node.js. Questo perché utilizza JavaScript (es. ECMAScript ) che non supporta il multi-threading (poiché JavaScript non era originariamente pensato per il server sviluppo laterale). Questo non significa che è non multi-thread. Al contrario, Node.js utilizza un pool di thread per gestire un sacco di I / O asincrono e un sistema di eventi che l'utente (l'utente di Node.js) può collegare (proprio come JavaScript sul client). Quindi come hai detto:

The precise phrasing is - you cannot spawn (or manage) threads in nodejs.

Sì.

can someone please compare these threads to a java environment by comparing their resource consumption on the server

In un ambiente Java, puoi generare thread nel codice utente, ma è necessario notare che i meccanismi sottostanti che generano i thread (cioè il codice JVM C) sono le stesse API di sistema chiamate a creare e gestire i thread in Node.js. In altre parole, entrambi chiameranno pthread_create per piattaforme POSIX o CreateThread per Windows. In questo modo, le risorse utilizzate sono le stesse su questo fronte.

Dove questo modello di thread e l'utilizzo delle risorse sono diversi quando un utente vuole creare più di 1 thread; più thread potrebbero significare switch di contesto che possono sostenere risorse aggiuntive. Questo è vero per qualsiasi linguaggio, dato che il threading è un concetto a livello di sistema operativo e non qualcosa di cui un linguaggio ha bisogno di supporto, quindi se (come lo sviluppatore) stai costruendo un'applicazione multi-thread, dovresti (dovresti) essere consapevole di questi avvertimenti e costruisci il tuo codice di conseguenza (ad es. gestisci le risorse / thread in modo tale che l'applicazione abbia il minimo cambiamento di contesto possibile).

Continuando da ciò, dichiari

as I also hear a lot about how nodejs is much less consuming than java.

Questa domanda non può essere risolta direttamente (leggi, facilmente) dal momento che una semplice app Node.js che è stata trasferita su Java (o viceversa) potrebbe portare a un utilizzo variabile delle risorse basato su una serie di fattori diversi e alla fine dovresti fai tu stesso il test per vedere quale sarebbe meglio per quello scenario.

Però, la citazione "meno consumante" probabilmente si riferisce più al fatto che l'esecuzione di un'applet basata su Java richiederebbe la Java Virtual Machine e l'ambiente Java, che fanno consumano quantità considerevoli di risorse (per ragioni diverse) rispetto a Node.js (che funziona come app "nativa"), ma solo perché qualcosa consuma più risorse non significa che sia "peggio". Ed è per questo che dovrebbero essere effettuati test aggiuntivi per confermare.

Spero che possa aiutarti ad aggiungere chiarezza.

Non è tanto Node.js, è JavaScript.

Java funziona con i thread. Quando devi fare più cose in parallelo, in genere assegni un thread per ogni attività. Quando un thread deve attendere qualcosa (una risposta da un server, una risorsa bloccata), quel thread viene messo in pausa fino a quando la risorsa è disponibile. Altri thread possono essere eseguiti durante questo periodo. Ogni thread ha il proprio stack ed esegue la propria sequenza di istruzioni indipendentemente dagli altri thread. In qualsiasi momento ci possono essere molti thread bloccati in alcune procedure, in attesa di vari motivi.

JavaScript, per tutti gli scopi pratici, funziona su un singolo thread. Il motore JavaScript eseguirà un pezzo di codice alla volta, in attesa che la procedura venga restituita prima di fare qualsiasi altra cosa. Una procedura non può attendere perché congelerebbe l'intera applicazione. Quindi un'applicazione JavaScript deve essere codificata usando molte piccole procedure che fanno il loro lavoro e ritornano prontamente. Non sono autorizzati ad aspettare in alcun modo.

Ecco perché la libreria runtime Java è progettata pensando al multithreading utilizzando un modello sincrono (una richiesta a un server non ritorna prima che il risultato sia disponibile), mentre la libreria JavaScript è scritta usando chiamate asincrone per tutto ciò che potrebbe bloccare (cioè "non aspettare, ti chiamo"). In JavaScript, chiameresti un metodo per avviare una richiesta e attendi che il motore java torni da te con la risposta quando è pronto.

Quindi è vero che Node.js non ha thread, ma è perché è il modo in cui funziona JavaScript. Node.js ti aiuta effettivamente a gestire questo. Semplifica la programmazione di un'applicazione multitasking (nel senso di più flussi di lavoro indipendenti in esecuzione in parallelo) assumendo la responsabilità di tessere quel singolo thread attraverso tutti i pezzi di codice che devono essere eseguiti, consentendo al tempo stesso di esprimere flussi di lavoro indipendenti ognuno dei quali esegue propria sequenza di eventi.