異步

異步

1.JavaScript單線程的理解

Javascript語言的執行環境是"單線程"（single thread）。所謂"單線程"，就是指一次只能完成一件任務。若是有多個任務，就必須排隊，前面一個任務完成，再執行後面一個任務，以此類推。

2.JavaScript單線程的優缺點

單線程模式的好處是實現起來比較簡單，執行環境相對單純；
壞處是隻要有一個任務耗時很長，後面的任務都必須排隊等着，會拖延整個程序的執行。常見的瀏覽器無響應（假死），每每就是由於某一段Javascript代碼長時間運行（好比死循環），致使整個頁面卡在這個地方，其餘任務沒法執行。

3.爲何JavaScript只能是單線程

JS代碼能夠修改DOM結構，若是JS是多線程的，當不一樣JS線程可能同時修改DOM結構，JS設計成單線程能夠避免DOM渲染衝突。Webwork支持多線程，可是不能訪問DOM。

4.爲何GUI渲染線程與JS引擎線程是互斥的

因爲JavaScript是可操縱DOM的，若是在修改這些元素屬性同時渲染界面（即JS線程和UI線程同時運行），那麼渲染線程先後得到的元素數據就可能不一致了。
所以爲了防止渲染出現不可預期的結果，瀏覽器設置GUI渲染線程與JS引擎爲互斥的關係，當JS引擎執行時GUI線程會被掛起， GUI更新則會被保存在一個隊列中等到JS引擎線程空閒時當即被執行。
因此若是JS執行的時間過長，這樣就會形成頁面的渲染不連貫，致使頁面渲染加載阻塞。

5.單線程的缺點解決方案——異步

Javascript語言將任務的執行模式分紅兩種：同步（Synchronous）和異步（Asynchronous）
"同步模式"就是上一段的模式，後一個任務等待前一個任務結束，而後再執行，程序的執行順序與任務的排列順序是一致的、同步的；
"異步模式"則徹底不一樣，每個任務有一個或多個回調函數（callback），前一個任務結束後，不是執行後一個任務，而是執行回調函數，後一個任務則是不等前一個任務結束就執行，因此程序的執行順序與任務的排列順序是不一致的、異步的。
"異步模式"很是重要。在瀏覽器端，耗時很長的操做都應該異步執行，避免瀏覽器失去響應，最好的例子就是Ajax操做。在服務器端，"異步模式"甚至是惟一的模式，由於執行環境是單線程的，若是容許同步執行全部http請求，服務器性能會急劇降低，很快就會失去響應。

6.Javascript做爲一種單線程語言，是如何實現異步編程的呢？

相信很多人對Javascript單線程表示懷疑：爲什麼單線程能夠實現異步操做呢？其實Javascript確實是單線程的（咱們不妨把這個線程稱做主線程），但它實現異步操做的方式確實藉助了瀏覽器的其餘線程的幫助。那其餘線程是怎麼幫助Javascript主線程來實現異步的呢？答案就是任務隊列（task queue）和事件循環（event loop）。

1、任務隊列
首先，做爲單線程語言，在Javascript中定義的任務都會在主線程中執行。可是並非每一個任務都會馬上執行，而這種不馬上執行的任務咱們稱做異步任務。相反，那些馬上執行的任務咱們把它們稱做同步任務。而這些異步任務都會交給瀏覽器的其餘線程去執行，可是主線程須要瞭解這些異步任務執行的狀態，才方便進行下一步操做。

打個比方，主線程準備作飯，因此下達一個異步任務去買菜，異步任務買完菜以後得告訴主線程：「我買完菜啦」，這個時候主線程纔好開始作飯。

而咱們知道由於Javascript是單線程，因此上述的「下一步操做」無法直接定義在主函數裏（否則就被當作同步任務直接執行了），那這些應該定義在哪裏呢？答案就是異步任務的回調函數中。在Javascript異步機制中，任務隊列就是用來維護異步任務回調函數的隊列。這樣一個隊列用來存放這些回調函數，它們會等到主線程執行完全部的同步函數以後按照先進先出的方式挨個執行。那麼執行完任務隊列以後呢？Javascript主線程就執行完畢了嗎？固然不是，否則網頁加載完畢以後，誰來處理後續與用戶的交互事件（好比點擊事件）呢？
2、事件循環
Javascript的異步機制:
執行同步任務 -> 檢查任務隊列中是否有任務 -> [有若是則執行] -> 檢查任務隊列中是否有任務 -> [有若是則執行] -> ......
可見主線程在執行完同步任務以後，會無限循環地去檢查任務隊列中是否有新的「任務」，若是有則執行。而這些任務包括咱們在異步任務中定義的回調函數，也包括用戶交互事件的回調函數。經過事件循環，Javascript不只很好的處理了異步任務，也很好的完成了與用戶交互事件的處理。由於在完成異步任務的回調函數以後，任務隊列中的任務都是由事件所產生的，所以咱們也把上述的循環過程叫作事件循環。

總而言之，Javascript單線程的背後有瀏覽器的其餘線程爲其完成異步服務，這些異步任務爲了和主線程通訊，經過將回調函數推入到任務隊列等待執行。主線程所作的就是執行完同步任務後，經過事件循環，不斷地檢查並執行任務隊列中回調函數。

7."異步模式"編程的4種方法

1、回調函數
這是異步編程最基本的方法。

假定有兩個函數f1和f2，後者等待前者的執行結果。若是f1是一個很耗時的任務，能夠考慮改寫f1，把f2寫成f1的回調函數。

function f1(callback){

　　　　setTimeout(function () {

　　　　　　// f1的任務代碼

　　　　　　callback();

　　　　}, 1000);

　　}
//執行代碼：

　　f1(f2);

採用這種方式，咱們把同步操做變成了異步操做，f1不會堵塞程序運行，至關於先執行程序的主要邏輯，將耗時的操做推遲執行。

回調函數的優勢是簡單、容易理解和部署，缺點是不利於代碼的閱讀和維護，各個部分之間高度耦合（Coupling），流程會很混亂，並且每一個任務只能指定一個回調函數。

2、事件監聽
另外一種思路是採用事件驅動模式。任務的執行不取決於代碼的順序，而取決於某個事件是否發生。

仍是以f1和f2爲例。首先，爲f1綁定一個事件（這裏採用的jQuery的寫法）。

function f1(){

　　　　setTimeout(function () {

　　　　　　// f1的任務代碼

f1.trigger('done');

　　　　}, 1000);

　　}


f1.on('done', f2);

這種方法的優勢是比較容易理解，能夠綁定多個事件，每一個事件能夠指定多個回調函數，並且能夠"去耦合"（Decoupling），有利於實現模塊化。缺點是整個程序都要變成事件驅動型，運行流程會變得很不清晰。
3、發佈/訂閱
上一節的"事件"，徹底能夠理解成"信號"。
咱們假定，存在一個"信號中心"，某個任務執行完成，就向信號中心"發佈"（publish）一個信號，其餘任務能夠向信號中心"訂閱"（subscribe）這個信號，從而知道何時本身能夠開始執行。這就叫作"發佈/訂閱模式"（publish-subscribe pattern），又稱"觀察者模式"（observer pattern）。
這個模式有多種實現，下面採用的是Ben Alman的Tiny Pub/Sub，這是jQuery的一個插件。
首先，f2向"信號中心"jQuery訂閱"done"信號。

jQuery.subscribe("done", f2);

function f1(){

　　　　setTimeout(function () {

　　　　　　// f1的任務代碼

jQuery.publish("done");

　　　　}, 1000);

　　}

jQuery.publish("done")的意思是，f1執行完成後，向"信號中心"jQuery發佈"done"信號，從而引起f2的執行。
此外，f2完成執行後，也能夠取消訂閱（unsubscribe）。　　

jQuery.unsubscribe("done", f2);

這種方法的性質與"事件監聽"相似，可是明顯優於後者。由於咱們能夠經過查看"消息中心"，瞭解存在多少信號、每一個信號有多少訂閱者，從而監控程序的運行。
4、Promises對象
Promises對象是CommonJS工做組提出的一種規範，目的是爲異步編程提供統一接口。
簡單說，它的思想是，每個異步任務返回一個Promise對象，該對象有一個then方法，容許指定回調函數。好比，f1的回調函數f2,能夠寫成：

f1().then(f2);

f1要進行以下改寫（這裏使用的是jQuery的實現）：

function f1(){
　　　　var dfd = $.Deferred();
　　　　setTimeout(function () {
　　　　　　// f1的任務代碼
　　　　　　dfd.resolve();
　　　　}, 500);
       return dfd.promise;
　　}

這樣寫的優勢在於，回調函數變成了鏈式寫法，程序的流程能夠看得很清楚，並且有一整套的配套方法，能夠實現許多強大的功能。
好比，指定多個回調函數：

　f1().then(f2).then(f3);

再好比，指定發生錯誤時的回調函數：

f1().then(f2).fail(f3);

並且，它還有一個前面三種方法都沒有的好處：若是一個任務已經完成，再添加回調函數，該回調函數會當即執行。因此，你不用擔憂是否錯過了某個事件或信號。這種方法的缺點就是編寫和理解，都相對比較難。

8.瀏覽器內核（渲染進程）

瀏覽器是多進程的
瀏覽器之因此可以運行，是由於系統給它的進程分配了資源（cpu、內存）
簡單點理解，每打開一個Tab頁，就至關於建立了一個獨立的瀏覽器進程（渲染進程）。

瀏覽器的渲染進程是多線程的，頁面的渲染，JS的執行，事件的循環，都在這個進程內進行。
渲染進程包含了哪些線程（列舉一些主要常駐線程）：
1.GUI渲染線程
負責渲染瀏覽器界面，解析HTML，CSS，構建DOM樹和RenderObject樹，佈局和繪製等。
當界面須要重繪（Repaint）或因爲某種操做引起迴流(reflow)時，該線程就會執行
注意，GUI渲染線程與JS引擎線程是互斥的，當JS引擎執行時GUI線程會被掛起（至關於被凍結了），GUI更新會被保存在一個隊列中等到JS引擎空閒時當即被執行。
2.JS引擎線程
也稱爲JS內核，負責處理Javascript腳本程序。（例如V8引擎）
JS引擎線程負責解析Javascript腳本，運行代碼。
JS引擎一直等待着任務隊列中任務的到來，而後加以處理，瀏覽器不管何時都只有一個JS線程在運行JS程序
一樣注意，GUI渲染線程與JS引擎線程是互斥的，因此若是JS執行的時間過長，這樣就會形成頁面的渲染不連貫，致使頁面渲染加載阻塞。
3.事件觸發線程
歸屬於瀏覽器而不是JS引擎，用來控制事件循環（能夠理解，JS引擎本身都忙不過來，須要瀏覽器另開線程協助）
當JS引擎執行代碼塊如setTimeOut時（也可來自瀏覽器內核的其餘線程,如鼠標點擊、AJAX異步請求等），會將對應任務添加到事件線程中
當對應的事件符合觸發條件被觸發時，該線程會把事件添加到待處理隊列的隊尾，等待JS引擎的處理
注意，因爲JS的單線程關係，因此這些待處理隊列中的事件都得排隊等待JS引擎處理（當JS引擎空閒時纔會去執行）
4.定時觸發器線程
傳說中的setInternal與setTimeout所在線程
瀏覽器定時計數器並非由JavaScript引擎計數的,（由於JavaScript引擎是單線程的, 若是處於阻塞線程狀態就會影響記計時的準確）
所以經過單獨線程來計時並觸發定時（計時完畢後，添加到事件隊列中，等待JS引擎空閒後執行）
注意，W3C在HTML標準中規定，規定要求setTimeout中低於4ms的時間間隔算爲4ms。
5.異步http請求線程
在XMLHttpRequest在鏈接後是經過瀏覽器新開一個線程請求
將檢測到狀態變動時，若是設置有回調函數，異步線程就產生狀態變動事件，將這個回調再放入事件隊列中。再由JavaScript引擎執行。

參考資料
1.JS異步編程異步編程的方法和原理