Shulou(Shulou.com)06/02 Report--

This article mainly explains "is nodejs a single process?". The explanation in the article is simple and clear, easy to learn and understand. Please follow the editor's train of thought to study and learn "is nodejs a single process?"

Nodejs is a single process. Node.js adopts single-threaded asynchronous non-blocking mode, that is, each calculation monopolizes the cpu, and the subsequent calculation is not blocked when it encounters a "Imax O" request. When the "Imax O" is completed, it is notified as an event to continue with the next calculation.

The operating environment of this tutorial: windows7 system, nodejs 12.19.0, Dell G3 computer.

Multithreaded and single threaded

Languages like java and python can be multithreaded. The multithreaded synchronization mode is that the cpu is divided into several threads, each running synchronously.

On the other hand, node.js adopts single-thread asynchronous non-blocking mode, that is, each calculation monopolizes the cpu, and the subsequent calculation will not be blocked when it encounters a request of Imax O. When it is completed, it will be notified in the form of an event and continue to execute calculation 2.

Event-driven, asynchronous, single-threaded, non-blocking nodejs O, this is the introduction we have heard most about it. When we see the keywords above, we may wonder:

Why can Javascript running in a browser interact with the operating system at such a low level?

Since nodejs is single-threaded, how to implement asynchronous and non-blocking ISCUBO?

Nodejs is all asynchronous invocation and non-blocking I Pot O, so you really don't care about the concurrent number?

How is nodejs event-driven implemented? Is it the same thing as the event loop of the browser?

What is nodejs good at? What are you not good at?

II. Internal revelation of nodejs

To understand the above problems, you must first figure out how nodejs works.

As we can see, the structure of Node.js is roughly divided into three levels:

1. Node.js standard library, which is written by Javascript, that is, we use API that can be called directly in the process. You can see it in the lib directory in the source code.

2. Node bindings, this layer is the key to the communication between Javascript and the underlying Cmax Candle +. The former calls the latter through bindings to exchange data with each other.

3. This layer is the key to support the operation of Node.js, which is implemented by C _ blank +.

Javascript VM, launched by V8:Google, is also the key to why Node.js uses Javascript. It provides an environment for Javascript to run on the non-browser side, and its efficiency is one of the reasons why Node.js is efficient.

Libuv: it provides Node.js with cross-platform, thread pool, event pool, asynchronous Imax O and other capabilities, which is the key to the power of Node.js.

C-ares: provides the ability to handle DNS-related issues asynchronously.

Http_parser, OpenSSL, zlib, etc.: provide other capabilities, including http parsing, SSL, data compression and so on.

III. Brief introduction of libuv

As you can see, almost all parts that deal with the operating system are inseparable from the support of libuv. Libuv is also the core of node's cross-operating system implementation.

4. Let's take a look at the first question I threw out at the beginning: why can Javascript running in a browser interact with the operating system at such a low level?

To take a simple example, if we want to open a file and do something, we can write a piece of code like this:

Var fs = require ('fs'); fs.open ('. / test.txt', "w", function (err, fd) {/ /. Do something}); fs.open = function (path, flags, mode, callback) {/ /. Binding.open (pathModule._makeLong (path), stringToFlags (flags), mode, callback);}

The calling process of this code can be roughly described as: lib/fs.js → src/node_file.cc → uv_fs

Call the core module of Node from JavaScript, the core module calls the built-in module of C++, and the built-in module makes system call through libuv, which is the classic way of calling in Node. In general, the methods we call in Javascript will eventually be passed through node-bindings to the Cmax Cobb + level, and they will eventually perform the actual operation. This is how Node.js interacts with the operating system.

Question 2: since nodejs is single-threaded, how to implement asynchronous and non-blocking I _ peg O?

By the way, is nodejs really single-threaded? In fact, only js execution is single-threaded, and IcanPot O is obviously other threads.

The js execution thread is single-threaded. Give the libuv what you need to do, go back and do something else immediately, and then libuv can call back at the specified time. In fact, the simplified process is purple! To be a little more detailed, nodejs will first call the js code through node-bindings to the CCMG + code, and then encapsulate something called the "request object" to the libuv through the Clibuv code. The request object contains nothing more than functions to be executed + callbacks and the like, to execute and implement callbacks for libuv.

To sum up, the general flow of an asynchronous Istroke O is as follows:

1. Initiate the Imax O call

The user calls the Node core module through Javascript code, passing parameters and callback functions to the core module.

The Node core module encapsulates the incoming parameters and callback functions into a request object

Push the request object into the Igamo thread pool to wait for execution

The asynchronous call initiated by Javascript ends and the Javascript thread continues to perform subsequent operations.

2. Execute callback

After the Javascript O operation is completed, the callback function encapsulated in the request object is taken out and the callback function is executed to complete the callback purpose. (the details of the callback here are explained below)

From here, we can see that we have always had a misunderstanding about the single thread of Node.js. In fact, its single thread refers to the single thread of its own Javascript runtime environment, Node.js does not give Javascript the ability to create new threads when it is executed, and the final actual operation is performed through Libuv and its event loop. This is why Javascript, a single-threaded language, can implement asynchronous operations in Node.js, and the two do not conflict.

Question 3: nodejs is all asynchronous calls and non-blocking Imax O, so you really don't care about the number of concurrency?

We mentioned the concept of thread pool earlier and found that nodejs is not single-threaded and parallel events occur. At the same time, the default size of the thread pool is 4, that is, four threads can work on the file iUniver at the same time, and the rest of the requests will be suspended until the thread pool is idle. So nodejs is limited by the number of concurrency.

The size of the thread pool can be changed through the environment variable UV_THREADPOOL_SIZE or reset through process.env.UV_THREADPOOL_SIZE in the nodejs code.

Question 4: how is nodejs event-driven implemented? Is it the same thing as the event loop of the browser?

Event loop is an execution model with different implementations in different places. Browsers and nodejs implement their own event loop based on different technologies.

To put it simply:

Nodejs's event is based on libuv, while browser's event loop is clearly defined in the html5 specification.

Libuv has implemented event loop, while the html5 specification only defines the model of event loop in browsers, leaving the implementation to browser vendors.

We mentioned above that libuv received the Imax O request passed by js, so when will the callback be handled?

Libuv has an event loop (event loop) mechanism to accept and manage the execution of callback functions.

Event loop is the core of libuv. As mentioned above, js will assign callbacks and tasks to libuv,libuv. When callbacks are called, event loop controls them. Event loop first maintains multiple event queues (or observer watcher) internally, such as time queues, network queues, and so on. Users can register callbacks in watcher. When events occur, events are transferred to pending state, and the next loop is taken out sequentially, while libuv executes an infinite loop equivalent to while true, constantly checking whether there are pending state events on each watcher that need to be processed. If so, the events stored in the queue are triggered sequentially, and since the libuv event loop executes only one callback at a time, competition is avoided. Event loop execution figure of Libuv:

The event loop of nodejs is divided into six phases, and the functions of each phase are as follows:

Timers: executes the expired callback in setTimeout () and setInterval ().

I callbacks O callbacks: a few I/Ocallback in the previous cycle will be delayed to this stage of the round.

Idle, prepare: internal use only

Poll: the most important phase, the execution of I _ callback O callback, will block at this stage under appropriate conditions.

Check: the callback that executes setImmediate

Close callbacks: the callback that executes the close event, such as socket.on ("close", func)

Each cycle of event loop needs to go through the above stages in turn. Each stage has its own callback queue. Every time it enters a certain stage, it will take the callback from the queue to execute. When the queue is empty or the number of callback executed reaches the maximum number of the system, proceed to the next phase. The completion of these six stages is called a cycle.

With event loop source code:

Int uv_run (uv_loop_t* loop, uv_run_mode mode) {int timeout; int r; int ran_pending / * We know from uv__loop_alive that the condition for event loop to continue is one of the following three: 1, there are active handles (libuv defines handle as some long-lived objects, such as tcp server) 2, there is active request 3 closing_handles * / r = uv__loop_alive (loop); if (! r) uv__update_time (loop) While (r! = 0 & & loop- > stop_flag = 0) {uv__update_time (loop); / / update the time variable, which is used in uv__run_timers using uv__run_timers (loop); / / timers phase ran_pending = uv__run_pending (loop) / / as can be seen from the libuv documents, this is actually the I callback phase. Ran_pending indicates whether the queue is empty uv__run_idle (loop); / / idle phase uv__run_prepare (loop); / / prepare phase timeout = 0 / * * set the timeout of the poll phase. The timeout will be set to 0 in the following cases, which means that the poll phase will not be blocked. In the following poll phase, we will discuss in detail that the 1 # stop stop flag is not 0 2, there is no active handles and request 3 callback, the handle queue of the close phase is not empty, otherwise, set to the callback queue of the timer phase. The * * / if closest to the current time ((mode = = UV_RUN_ONCE & &! ran_pending) | | mode = = UV_RUN_DEFAULT) timeout = uv_backend_timeout (loop) Uv__io_poll (loop, timeout); / / poll phase uv__run_check (loop); / / check phase uv__run_closing_handles (loop) / / close phase / / if mode = = UV_RUN_ONCE (meaning the process continues to move forward), timers will be checked again after all phases. The logical reason for this is unclear. If (mode = = UV_RUN_ONCE) {uv__update_time (loop); uv__run_timers (loop);} r = uv__loop_alive (loop) If (mode = = UV_RUN_ONCE | | mode = = UV_RUN_NOWAIT) break;} if (loop- > stop_flag! = 0) loop- > stop_flag = 0; return r;}

Let's take a closer look at the poll phase here:

The poll phase has two main functions:

1. Timers callback for which the lower limit of time has been reached.

2. Handle the events in the poll queue.

When event loop enters the poll phase and there is no set timers (there are no timers scheduled), one of the following two things happens:

1. If the poll queue is not empty, event loop will traverse the queue and synchronously execute callbacks until the queue is emptied or the number of callbacks reached the system limit

2. If the poll queue is empty, one of the following two things occurs:

(1) if the code has been set to callback by setImmediate (), event loop will end the poll phase and enter the check phase to execute the check queue (callback in).

(2) if the code is not callback set by setImmediate (), event loop will block at this stage and wait for the callback to be added to the poll queue and executed immediately.

However, when event loop enters the poll phase and has a set timers, once the poll queue is empty (the poll phase is idle):

Event loop will check the timers, and if the lower limit of time for one or more timers has reached, the event loop will go back to the timers phase.

An example of event loop describes:

Var fs = require ('fs'); function someAsyncOperation (callback) {/ / suppose this task consumes 95ms fs.readFile (' / path/to/file', callback);} var timeoutScheduled = Date.now (); setTimeout (function () {var delay = Date.now ()-timeoutScheduled; console.log (delay + "ms have passed since I was scheduled");}, 100); / / someAsyncOperation consumes 95ms to complete someAsyncOperation (function () {var startCallback = Date.now ()) / / consume 10ms. While (Date.now ()-startCallback < 10) {; / / do nothing}})

When event loop enters the poll phase, it has an empty queue (fs.readFile () is not yet finished). So it waits for the remaining milliseconds until the recent lower limit of timer time is up. When it waits for 95ms force. ReadFile () to finish first, then its callback is added to the queue of poll and executed-- this callback takes 10ms. Since there are no other callbacks in the queue, event loop will check the lower limit time of the recently reached timer, and then go back to the timers phase to execute the callback of timer.

So in the example, the interval between the callback being set and the callback execution is 105ms.

At this point, let's summarize the whole process of asynchronous IO:

Question 5. What is nodejs good at? What are you not good at?

Node.js handles interaction with the operating system through libuv, and therefore has the ability to be asynchronous, non-blocking, and event-driven. As a result, NodeJS can respond to a large number of concurrent requests. Therefore, NodeJS is suitable to be used in scenarios with high concurrency, dense I-Pot O and a small amount of business logic.

As mentioned above, if it is an Imax O task, Node.js hands the task over to the thread pool for asynchronous processing, which is efficient and simple, so Node.js is suitable for handling Imax O-intensive tasks. But not all tasks are CPU O-intensive tasks. When it comes to CPU-intensive tasks, that is, operations that only use CPU computing, such as data encryption and decryption (node.bcrypt.js), data compression and decompression (node-tar), Node.js will personally handle the calculation, one by one, the previous task is not finished, the following task can only wait. Let's look at the following code:

Var start = Date.now (); / / get the current timestamp setTimeout (function () {console.log (Date.now ()-start); for (var I = 0; I < 100000000; iTunes +) {/ / CEO cycle}, 1000); setTimeout (function () {console.log (Date.now ()-start);}, 2000)

In the end, our print result is: (the result may vary depending on your machine)

one thousand

3738

For the setTimeout function that we expect to execute in 2 seconds, it actually takes 3738 milliseconds to execute, in other words, our entire Node.js main thread is blocked because of a long for loop, and if the first of our 100 user requests requires such a large amount of computation, then the other 99 will be delayed. If the operating system itself is a single core, then forget it, but now most servers are multi-CPU or multi-core, while Node.js has only one EventLoop, that is, only one CPU kernel. When Node.js is occupied by CPU-intensive tasks, causing other tasks to be blocked, there are CPU kernels idle, resulting in a waste of resources.

In fact, although Node.js can handle thousands of concurrency, a Node.js process is actually processing a request at some point.

Therefore, Node.js is not suitable for CPU-intensive tasks.

Thank you for your reading, the above is the content of "is nodejs a single process?" after the study of this article, I believe you have a deeper understanding of the problem that nodejs is a single process, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.