How JavaScript timers work

Before reading the following content, read a small piece of code. If the reader can tell the purpose of the code, there is no need to read further, because you will understand it.

setTimeout(function(){
/* Some long block of code… */
setTimeout(arguments.callee, 10);
}, 10);
setInterval(function(){
/* Some long block of code… */
}, 10);

The timer is a very cool thing, but many people only know its syntax and lack understanding of its principles. A timer executes a piece of code asynchronously by setting a certain period of time (milliseconds). Because Javascript is a single-threaded language, timers provide the ability to execute code around this language limitation.

Today I will briefly explain how the timer works.

JavaScript provides three functions to build and operate timers

1 var id = setTimeout(fn, delay);

2 var id = setInterval(fn, delay);

3 clearInterval(id); clearTimeout( id);

I won’t go into details about the specific syntax, you can check the manual. In order to understand how timers work, one concept must be kept in mind: time delays are not guaranteed. What does it mean? Just because you write setTimeout(fn, 500) like this does not mean that fn will definitely be executed immediately after 500 milliseconds. The delay is likely to be longer. Because JavaScript is a single-threaded language, all asynchronous events (including timers, mouse events, or the completion of an XMLHttpRequest) will only be executed when there is a gap during program execution. It does not mean that it will be executed when you specify it. You must know the program Users are not omnipotent, and what you write will ultimately depend on the browser.

The picture below can illustrate the problem very well, thank you to the great John Resig.

Looking from top to bottom, the numbers on the left represent time (milliseconds), the text on the right represents the setting and triggering of a series of asynchronous events, and the code block in the middle. The top JavaScript code block may be the fragment you execute when the browser loads, which takes about 18 milliseconds. The Mouse Click Callback code block immediately below may be your callback function when a mouse event is triggered, which takes about 18 milliseconds. 11 milliseconds, and so on.

The single-threaded nature of JavaScript determines that only one block can be executed at a time, so when the first block of code is executed (it ran for a total of 18 milliseconds), it constructed two timers, during which the user may have clicked the mouse. (Have you ever had a webpage get messed up as soon as it was opened before it finished loading?) It stands to reason that the callback function should be executed immediately after the user clicks the mouse, but no, there is only one lane for JavaScript execution. Before the 18 milliseconds are completed, other code blocks can only be queued up if they want to be executed, and there is no room for you to overtake. Both timers have a delay of 10 milliseconds. As you can see from the picture, setTimeout is also triggered before the end of the 18 millisecond execution. There is no way to queue it up.

Finally, 18 milliseconds later, a divine thunder from the sky split the car in front into thin air. The two people in line behind could pass, but they had to go one by one and couldn't be side by side. So who would go through first? Are two people punching each other there? No, the browser has the final say. The browser says that the mouse click event passes first, and setTimeout can only continue to wait for 11 milliseconds. Pay attention to the picture. When the mouse event callback function is executed, another timer event is triggered (setInterval), waiting, and must be ranked behind setTimeout.

11 milliseconds have passed, and setTimeout has finally passed. Note that setInterval is triggered for the second time. Although it was queued the first time, if it is still queued as usual at this time, what will happen in the end? SetTimeout is executed. After that, two setIntervals will be executed continuously, and the delay you set will be useless. Therefore, the browser is relatively smart. When it processes setInterval, if it finds that there is already a queued one, it will directly kill the new one.

Look next, it is the queued setInterval's turn to be triggered for the first time and start executing. When it is executed, the third trigger comes again. This time there is no queue, so the browser does not kill it and gives you a chance to queue. , so you will find that there is no interval between the execution of these two setIntervals. If you are making a slideshow, you should think carefully about whether there is a problem with your code when encountering this situation.

Finally, no other factors interfere with setInterval (if the user is called away by MM), setInterval will be executed according to the steps you want.

At this point, the code at the beginning can be understood.

setTimeout(function(){
/* Some long block of code… */
setTimeout(arguments.callee, 10);
}, 10);
setInterval(function(){
/* Some long block of code… */
}, 10);

These two functions seem to have the same effect, but they are not. The first code block will always be executed with a delay of 10 milliseconds, although most of the time it is greater than 10 milliseconds. The second one tries to execute every 10 milliseconds, regardless of whether the previous trigger has been executed.

In summary, four points

• The JavaScript engine has only one thread, which will force certain asynchronous events to be queued

• There is a big difference between setTimeout and setInterval when executing asynchronous code

• If a timer is blocked from executing, it Will wait until encountering a code execution gap, usually longer than expected

• Intervals may be executed one after another, if the execution time of the callback function is greater than the interval