標籤:使用者 zed on() pen 老版本 cti ros 時間 排隊
一、為什麼JavaScript是單線程?
因為JS運行在瀏覽器中,是單線程的,每個window一個JS線程,既然是單線程的,在某個特定的時刻只有特定的代碼能夠被執行,並阻塞其它的代碼。而瀏覽器是事件驅動的(Event driven),瀏覽器中很多行為是非同步(Asynchronized)的,會建立事件並放入執行隊列中。javascript引擎是單線程處理它的任務隊列,你可以理解成就是普通函數和回呼函數構成的隊列。當非同步事件發生時,如mouse click, a timer firing, or an XMLHttpRequest completing(滑鼠點擊事件發生、定時器觸發事件發生、XMLHttpRequest完成回調觸發等),將他們放入執行隊列,等待當前代碼執行完成。
JavaScript語言的一大特點就是單線程,也就是說,同一個時間只能做一件事。那麼,為什麼JavaScript不能有多個線程呢?這樣能提高效率啊。
JavaScript的單線程,與它的用途有關。作為瀏覽器指令碼語言,JavaScript的主要用途是與使用者互動,以及操作DOM。這決定了它只能是單線程,否則會帶來很複雜的同步問題。比如,假定JavaScript同時有兩個線程,一個線程在某個DOM節點上新增內容,另一個線程刪除了這個節點,這時瀏覽器應該以哪個線程為準?
所以,為了避免複雜性,從一誕生,JavaScript就是單線程,這已經成了這門語言的核心特徵,將來也不會改變。
瀏覽器不是單線程:
雖然JS運行在瀏覽器中,是單線程的,每個window一個JS線程,但瀏覽器不是單線程的,例如Webkit或是Gecko引擎,都可能有如下線程:
javascript引擎線程
介面渲染線程
瀏覽器事件觸發線程
Http請求線程
Ajax非同步請求是否真的非同步?
其實請求確實是非同步,這請求是由瀏覽器新開一個線程請求(瀏覽器是多線程的)。當請求的狀態變更時,如果先前已設定回調,這非同步線程就產生狀態變更事件放到 JavaScript引擎的事件處理隊列中等待處理。當瀏覽器閒置時候出隊列任務被處理,JavaScript引擎始終是單線程運行回呼函數。javascript引擎確實是單線程處理它的任務隊列,能理解成就是普通函數和回呼函數構成的隊列。
總結一下,Ajax請求確實是非同步,這請求是由瀏覽器新開一個線程請求,事件回調的時候是放入Event loop單線程事件隊列等候處理。
二、任務隊列
單線程就意味著,所有任務需要排隊,前一個任務結束,才會執行後一個任務。如果前一個任務耗時很長,後一個任務就不得不一直等著。
如果排隊是因為計算量大,CPU忙不過來,倒也算了,但是很多時候CPU是閑著的,因為IO裝置(輸入輸出裝置)很慢(比如Ajax操作從網路讀取資料),不得不等著結果出來,再往下執行。
JavaScript語言的設計者意識到,這時主線程完全可以不管IO裝置,掛起處於等待中的任務,先運行排在後面的任務。等到IO裝置返回了結果,再回過頭,把掛起的任務繼續執行下去。
於是,所有任務可以分成兩種,一種是同步任務(synchronous),另一種是非同步任務(asynchronous)。同步任務指的是,在主線程上排隊執行的任務,只有前一個任務執行完畢,才能執行後一個任務;非同步任務指的是,不進入主線程、而進入"任務隊列"(task queue)的任務,只有"任務隊列"通知主線程,某個非同步任務可以執行了,該任務才會進入主線程執行。
具體來說,非同步執行的運行機制如下。(同步執行也是如此,因為它可以被視為沒有非同步任務的非同步執行。)
(1)所有同步任務都在主線程上執行,形成一個執行棧(execution context stack)。
(2)主線程之外,還存在一個"任務隊列"(task queue)。只要非同步任務有了運行結果,就在"任務隊列"之中放置一個事件。
(3)一旦"執行棧"中的所有同步任務執行完畢,系統就會讀取"任務隊列",看看裡面有哪些事件。那些對應的非同步任務,於是結束等待狀態,進入執行棧,開始執行。
(4)主線程不斷重複上面的第三步。
只要主線程空了,就會去讀取"任務隊列",這就是JavaScript的運行機制。這個過程會不斷重複。
三、事件和回呼函數
"任務隊列"是一個事件的隊列,IO裝置完成一項任務,就在"任務隊列"中添加一個事件,表示相關的非同步任務可以進入"執行棧"了。主線程讀取"任務隊列",就是讀取裡面有哪些事件。
"任務隊列"中的事件,除了IO裝置的事件以外,還包括一些使用者產生的事件(比如滑鼠點擊、頁面滾動等等)。只要指定過回呼函數,這些事件發生時就會進入"任務隊列",等待主線程讀取。
所謂"回呼函數"(callback),就是那些會被主線程掛起來的代碼。非同步任務必須指定回呼函數,當主線程開始執行非同步任務,就是執行對應的回呼函數。
"任務隊列"是一個先進先出的資料結構,排在前面的事件,優先被主線程讀取。主線程的讀取過程基本上是自動的,只要執行棧一清空,"任務隊列"上第一位的事件就自動進入主線程。但是,由於存在"定時器"功能,主線程首先要檢查一下執行時間,某些事件只有到了規定的時間,才能返回主線程。
四、定時器
除了放置非同步任務的事件,"任務隊列"還可以放置定時事件,即指定某些代碼在多少時間之後執行。這叫做"定時器"(timer)功能,也就是定時執行的代碼。
定時器功能主要由setTimeout()和setInterval()這兩個函數來完成,它們的內部運行機制完全一樣,區別在於前者指定的代碼是一次性執行,後者則為反覆執行。以下主要討論setTimeout()。
setTimeout()接受兩個參數,第一個是回呼函數,第二個是延遲執行的毫秒數。
Js代碼
- console.log(1);
- setTimeout(function(){console.log(2);},1000);
- console.log(3);
上面代碼的執行結果是1,3,2,因為setTimeout()將第二行延遲到1000毫秒之後執行。
如果將setTimeout()的第二個參數設為0,就表示當前代碼執行完(執行棧清空)以後,立即執行(0毫秒間隔)指定的回呼函數。
Js代碼
- setTimeout(function(){console.log(1);}, 0);
- console.log(2);
上面代碼的執行結果總是2,1,因為只有在執行完第二行以後,系統才會去執行"任務隊列"中的回呼函數。
總之,setTimeout(fn,0)的含義是,指定某個任務在主線程最早可得的空閑時間執行,也就是說,儘可能早得執行。它在"任務隊列"的尾部添加一個事件,因此要等到同步任務和"任務隊列"現有的事件都處理完,才會得到執行。
HTML5標準規定了setTimeout()的第二個參數的最小值(最短間隔),不得低於4毫秒,如果低於這個值,就會自動增加。在此之前,老版本的瀏覽器都將最短間隔設為10毫秒。另外,對於那些DOM的變動(尤其是涉及頁面重新渲染的部分),通常不會立即執行,而是每16毫秒執行一次。這時使用requestAnimationFrame()的效果要好於setTimeout()。
需要注意的是,setTimeout()只是將事件插入了"任務隊列",必須等到當前代碼(執行棧)執行完,主線程才會去執行它指定的回呼函數。要是當前代碼耗時很長,有可能要等很久,所以並沒有辦法保證,回呼函數一定會在setTimeout()指定的時間執行。
js運行機制