On the delay parameters of setTimeout

guys, let me ask you a question:
Why does the following code output 1 , 4 , 3 , 2 , but not 1 , 4 , 2 , 3 ; When the
js main thread executes from top to bottom, it will be inserted into the task queue when it encounters asynchronous code. Should the task queue be 1000 before 0, or should the setTimeout second parameter delay inserting it into the task queue?

console.log(1);
setTimeout(function () {
    console.log(2);
}, 1000);
setTimeout(function () {
    console.log(3);
}, 0);
console.log(4);

result:

Sep.03,2021

console.log(1);//
setTimeout(function () {
    console.log(2);//1
}, 1000);
setTimeout(function () {
    console.log(3);//000
}, 0);
console.log(4);//

the second parameter I understand is how long it takes to execute


after joining the asynchronous queue.

because the delay time of output 3 is 0 and the delay time of input 2 is 1000!
setTimeout (code,millisec)

< table > < thead > < tr > < th > parameters < / th > < th > description < / th > < / tr > < / thead > < tbody > < tr > < td > code < / td > < td > required. The JavaScript code string to be executed after the function to be called. < / td > < / tr > < tr > < td > millisec < / td > < td > required. The number of milliseconds to wait before executing the code. < / td > < / tr > < / tbody > < / table >

the subject seems to have a misunderstanding about js's task queue. It is because js is single-threaded that there is this task queue mechanism, but the task queue is not single-threaded and can be multitasking [implemented by the browser] by Synchronize.
so your two setTimeout basically entrust the browser to perform timing operations asynchronously at the same time. If the browser calls the callback function according to the time you set, the one set to 0 must have triggered


the second delay is 1 second, of course, it will be executed


later than the third delay of 0 seconds.

you can take a look at the elder Ruan Yifeng's explanation on timer operation mechanism, which may help you solve the problem http://javascript.ruanyifeng..

another point is that the timer is timed and triggered by a separate thread (added to the event loop queue after timing is completed, and executed after waiting for the JS engine to be idle), which is not counted by the js engine

.
setTimeout(function () {
    console.log(2);
}, 1000);
setTimeout(function () {
    console.log(3);
}, 500ms);
//  3  2

there is no problem with your understanding: when the js main thread executes from top to bottom, it will be inserted into the task queue when it encounters asynchronous code. The task queue should be 1000 before 0. Wait until the task of the main thread is executed, and then execute the task of the task queue, but the timer set by the setTimeout () method.
but there is one thing you misunderstand. Look at the code above, not waiting for 1000ms output 2 set by setTimeout above, and then waiting for 500ms output 3 set by setTimeout below, but waiting for 500ms first, the time set below setTimeout is up, output 3, and then past 500ms (1000ms-500ms), the time set by setTimeout above is up, output 2.
so the total waiting time is 1000ms, not 1000ms + 500ms as you understand


1000 does precede 0, but checking the queue after the console.log (4) cycle shows that 1000 of the time has been skipped before the time is up.


the second parameter of setTimeout (fn, delay) can be defaulted by default. If it is not passed, the browser will automatically add it to the task queue of the browser. When the next round of events starts, the delay time is uncertain. However, if the parameter is passed, it does not mean that the function will be executed after the specified time (the time varies from browser to browser)

.
Menu