The browser is suspended due to setTimeout.

 Problem

A few days ago, my colleague encountered a browser zombie problem. That is, when the browser responds to a request, it suddenly does not respond to the time, enters the false dead state, and the cup also soared to 100%. however, this problem only occurs in IE, chrome, Firefox, and other browsers.

Cause

In the JS Code, there are no time-consuming operations or background asynchronous calls. No. You can only perform further investigation from the very beginning of the incident response. After some debugging, the problem is located in the setTimeout function. This will not happen immediately after the functions executed in setTimeout are removed. Check the functions called in setTimeout and find some Dom operations in JS. html splicing is also performed in the functions. Is this the cause. The reason for online query: When a JS script occupies a processing machine for a long time, the browser's Gui update will be suspended, and subsequent event responses will not be processed in the queue, as a result, the browser is locked and enters the suspended state. To put it bluntly, the browser cannot execute JS while rendering the page. In the setTimeout function, there are some cases of HTML splicing and Dom operations. It may be that when Javascript is executed, there are some HTML operations in the JS Code. As a result, the browser cannot render the page, and JS is operating on the page content. Cause the browser to become stuck.

Browser kernel processing method:

The browser kernel is multi-threaded. They work with each other under the kernel control to maintain synchronization. A browser must implement at least three resident threads: JavaScript Engine threads, Gui rendering threads, and browser event triggering threads.

1. The JavaScript engine is based on the event-driven single-thread execution. The JS engine is waiting for the arrival of tasks in the task queue to be processed, the browser has only one JS thread running the JS program at any time.
2. The GUI rendering thread is responsible for rendering the browser interface. When the interface needs to be repainted or reflow is triggered due to some operation, this thread will execute. However, you must note that the GUI rendering thread and JS engine are mutually exclusive. When the JS engine is executed, the GUI thread will be suspended, gui updates are saved in a queue and executed immediately when the JS engine is idle.
3. Event trigger thread. When an event is triggered, the thread adds the event to the end of the queue to be processed, waiting for processing by the JS engine. These events can come from the code blocks currently executed by the JavaScript engine, such as setTimeout, other threads from the browser kernel, such as mouse clicks and Ajax asynchronous requests, however, because of the single-threaded relationship of JS, all these events have to be queued for processing by the JS engine.

 

After understanding the browser kernel processing method, you can understand why the browser is in a suspended state. When a Javascript script takes up CPU time for a long time, the browser's Gui update will be suspended, however, the subsequent event responses are not processed in the queue, causing the browser to be locked and enter the suspended state. In addition, Dom operations are performed in the JS script. Once the JS call ends, a GUI rendering is performed immediately before the next task is executed, therefore, a large number of Dom operations in Javascript will also lead to slow Event Response and even slow browser freezing.

 

This article is more thorough: http://www.nowamagic.net/librarys/veda/detail/787