Learning about JavaScript running mechanism from a face test

Today in the Internet to see a javascript on the surface of the test, try to look at it, it is normal to do wrong, and then give us the front-end to do, haha, he incredibly also naturally do wrong, the code is probably like this

/*1 What does the following code do? What is the result of the execution */
  var  i=true  ;        SetTimeout ( ' stoploops () ', 2000 function   loops () {alert ( ' no hell o world! '             while   (i) {}  function   Stoploops () {i             =false  ; Alert ( ' Hello world! '        

A cursory look at the above code, your first impression is that the browser executes the Stoploops function after the Web page opens for two seconds, turns the value of I to false and then pops up Hello world! And then perform the loops function pop-up no Hello world! , because the value of I is false so it does not go into the dead loop, so the code execution ends, but the actual operation of the code is not the case.

After I consulted carefully a study, found that things are not simple, this problem is implicated in the JavaScript code in the browser operating mechanism, and settimeout and setinterval function is two downright "big liar", The documentation for the introduction of settimeout () is also: The method is used to call a function or evaluate an expression after a specified number of milliseconds.

In many cases, however, the functions called by the settimeout and setinterval functions do not necessarily execute in the time specified by the parameter, such as the above code, and the result of the above code is that the browser executes the loops () function The first time the Web page is opened and then pops up no Hello world! The pop-up window, and then because of the i=true, will be infinite loop, until the power outage, will never execute the Stoploops function.

If you are a regular player, it may be a bit unacceptable for this kind of reality, because the regular code is executed sequentially, which is a bit counterintuitive, but the fact is that the code executes in the second way I say it.

and figure out why it's so uncomfortable. Routine implementation, for in-depth learning and understanding JS are very important.

The following is the mystery of the problem, its execution order dislocation of its essence is because:JavaScript engine is single-threaded, the browser whenever only and only one thread running JavaScript program.

Of course you understand the meaning of this sentence. You first need to know what a thread is: a thread is the smallest unit of a program's execution flow. About the thread and process-related details of things are also more complex, a word is not clear, of course, in order to understand the following content, you can simply understand the thread as a small "CPU", it can only do one thing at a time, like if a person, at the same time, he was at dinner, It opens up a thread that is responsible for eating, the thread can only eat, can't do other things at the same time, if he wants to eat while eating while watching TV, it is necessary to enable another two threads, a thread responsible for eating, a thread responsible for watching TV. So I think you can understand the above sentence: theJavaScript engine is single-threaded, the browser at any time only and only one thread is running the JavaScript program. Simply say a browser (the browser is a process) is responsible for executing the JS code of the thread only one, and settimeout and SetInterval used a decoy, creating a false impression, as if the function of the two performed by themselves is enabled by a new thread to execute, In fact, there is no new thread to be enabled, from a language design perspective, JavaScript single-threaded runtime has its advantages, JavaScript as the browser scripting language, its main purpose is to interact with the user, as well as manipulate the DOM. This determines that it can only be single-threaded, or it will bring a very complex synchronization problem (want to be true one day, JS becomes multi-threading, if the complex thread conflict and data synchronization problems are dropped to JS, to the front end, he will say I m is just a painting interface, what fuck? Greet your family for me).

So javascript divides the code task into two, one is the code of the synchronous Task (synchronous), the other is the asynchronous task (asynchronous) code (the asynchronous task code corresponds to an event queue, which controls the order of execution of the asynchronous code). The JavaScript engine takes precedence over the code of the synchronization task, and then executes the asynchronous code sequentially after all the synchronization tasks have been executed, and if the CPU computation occurs during the execution of the synchronization code, it will take a long time, and the asynchronous code will be executed sequentially after the synchronization code execution is complete. , the code we normally write is the synchronous task code, and the code executed in settimeout and SetInterval is the asynchronous task code. So now look back at the topic above, because the loops function is the synchronous task code, the JavaScript engine executes the loops function first, but the loops function has a dead loop, so the JavaScript engine thread is stuck for a long time and cannot execute subsequent code ... Finally the truth!

Extended:

1, through the above learning, if you encounter the synchronization task is relatively time-consuming, we can put the time-consuming code into the settimeout to execute, so the JavaScript engine will be the first to execute the fast execution of the synchronization task code, now can render the part first rendered, Make the user experience even better

The 2,javascript engine is a single-threaded operation! = The entire Web page is single-threaded, the browser kernel implementation allows multiple threads to execute asynchronously, in addition to the JavaScript engine thread, there will be interface rendering thread, browser event trigger thread, related request thread, etc.

Interface rendering Thread: The thread is responsible for rendering the browser interface HTML element, which executes when the interface needs to be redrawn (Repaint) or because of an operation that causes reflux (reflow), which is mutually exclusive to the JavaScript engine thread. So it's easy to understand why the interface rendering thread renders HTML elements when the JavaScript engine thread is blocked, leaving the interface blank.

Event Trigger Thread: When an event is triggered, the thread adds the event to the end of the queue to be processed and waits for the JS engine to process. These events can come from code blocks currently executing by the JavaScript engine, such as settimeout, other threads from the browser kernel such as mouse clicks, Ajax asynchronous requests, and so on, but because of the JS single-threaded relationship all of these events are queued for the JS engine to process.

Timed trigger Thread: The browser model timer counter is not counted by the JavaScript engine because the JavaScript engine is single-threaded, and if it is not counted when it is in a blocked thread state, it must rely on the outside to timing and trigger the timing

3, since JS is a single-threaded language, how does the XMLHttpRequest object implement AJAX asynchronous requests?

The request is actually asynchronous, but the request is made by the browser to open a new thread request, when the state of the request changes, if the callback was previously set, this asynchronous thread will produce a state change event in the JavaScript engine processing queue to wait for processing, when the task is processed, The JavaScript engine is always a single-threaded run callback function, or a single-threaded run of the functions set by onReadyStateChange, but the synchronization task can block the JavaScript engine thread code before executing an AJAX asynchronous request. The interface has been stuck for a long time, unable to perform other operations until the synchronization task is completed, unblocked, and the interface can do other things

Reference article:

Http://www.ruanyifeng.com/blog/2014/10/event-loop.html

Http://www.iamued.com/qianduan/1645.html

Learning about JavaScript running mechanism from a face test