just like the bank queue, there is only one window, that is, single thread, to serve one by one. When someone comes out because of a temporary delay, he or she will come out and continue the queue after finishing the work, so it is not blocked

this problem can be divided into two parts:

single thread

javascript the runtime contains only one message queue , where each message corresponds to an associated function. This queue follows the FIFO (first in first out) mechanism, and always starts processing from the first incoming message. When processing:

1. this message will be removed from the queue, and take this message to find its corresponding function
The
2. function starts to execute until it completes
3. fetch the next message in the message queue, and then go to 1

non-blocking

when making an IO or network request, it is usually done through the event and the callback mechanism . For example, when sending a json asynchronous data request, it will think that the function has been executed and will continue to get the next message from the message queue for processing. When the network request returns, a new message is crammed into the queue and continues to wait for processing.

but there are exceptions, such as alert dialog box or Synchronize XHR . If the processing is not completed, the message queue will be blocked all the time. Of course, unless there are special occasions, we should try to avoid this situation .

as we all know, javascript has been a single-threaded, non-blocking scripting language since its birth. This is determined by its original use: interacting with browsers.

single threading means that at any time the javascript code is executed, there is only one main thread to handle all tasks.

non-blocking means that when the contemporary code needs to perform an asynchronous task (a task that cannot return the result immediately and takes a certain amount of time to return, such as the Iripo event), the main thread will suspend the (pending) task, and then execute the corresponding callback according to certain rules when the asynchronous task returns the result.

single threading is necessary and the cornerstone of the javascript language, one of the reasons why we need to do a variety of dom operations in its original and primary execution environment, the browser. Imagine if javascript is multithreaded, what happens when two threads perform an operation on the dom at the same time, such as one adding an event to it and the other deleting the dom,? Therefore, to ensure that a scenario similar to that in this example does not occur, javascript chooses to use only one main thread to execute the code, thus ensuring the consistency of program execution.

of course, nowadays people also realize that single thread not only ensures the order of execution but also limits the efficiency of javascript, so web worker technology has been developed. This technology claims to make javascript a multithreaded language.

however, multithreading using web worker technology has many limitations, for example, all new threads are under the full control of the main thread and cannot be executed independently. This means that these "threads" should actually belong to the children of the main thread. In addition, these child threads do not have permission to perform the Icano operation, so they can only share some tasks such as computation for the main thread. So strictly speaking, these threads do not have full functionality, so this technology does not change the single-threaded nature of the javascript language.

predictably, javascript will always be a single-threaded language in the future.

you just need to understand single thread. Non-blocking means that it is asynchronous. In fact, it is realized by multithreading or multi-processes at the bottom of the host environment. No matter how to implement it, there is only one thread you can play with. It is designed like this in design, but there are various ways to play in implementation, so it is emphasized that in terms of design