javascript基礎修煉(7)——Promise，異步，可靠性

時間 2020-01-23

標籤 javascript 基礎修煉 promise 異步可靠性欄目 JavaScript 简体版

原文原文鏈接

開發者的javascript造詣取決於對【動態】和【異步】這兩個詞的理解水平。javascript

一. 別人是開發者，你也是

Promise技術是【javascript異步編程】這個話題中很是重要的，它一度讓我感到熟悉又陌生，我熟悉其全部的API並可以在編程中相對熟練地運用，卻對其中原理和軟件設計思想感到陌生，即使我讀了不少源碼分析和教程也一度很難理解爲何Promise這樣一個普通的類可以實現異步，也曾嘗試着去按照Promise/A+規範來編寫Promise,但很快便陷入了一種更大的混亂之中。直到我接觸到一些軟件設計思想以及軟件工程方面的知識後，從代碼以外的角度來理解一些細節的必要性時，那些陌生纔開始一點點消失。html

若是你以爲有些新東西很那理解，有很大的緣由是由於你和設計者所擁有的基礎知識儲備不是一個水平的，致使你沒法理解設計者寫出某段代碼時所基於的指導思想，當你沒法理解某些看起來很複雜的東西時，筆者的建議是先了解它但願解決的問題，這個問題或許是具體的業務邏輯需求，或許是抽象的軟件設計層面的，而後嘗試本身想辦法去解決它，請永遠記得別人是開發者，你也是，你要作的是面向需求，而不只僅是跟着別人走。即時最終你沒能開發出這個模塊而去學習源碼時，你也會發現面對需求而進行的主動思考對此帶來的幫助。java

二. 關於Promise的一些困惑

Promise的本質，是一個分佈式的狀態機。而PromiseAPI的本質，就是一個發佈訂閱模型。node

Promise解決了什麼問題？git

這是一個最基本的問題，Promise是一個有關可靠性和狀態管理的編程範式，它一般被認爲從代碼層面將javascript中著名的回調地獄改變成扁平化的寫法，併爲指定的業務邏輯打上狀態標記，讓開發者能夠更容易地控制代碼執行的流程。但事實上Promise的設計初衷並非爲了實現異步，並且不少開發者並無意識到，回調並不意味着異步！！！（你傳入另外一個函數的回調函數有可能被異步執行，也有可能被同步執行）。想更好地理解Promise，就必須把【異步】這個標籤從中剝離，而圍繞【狀態管理】，【可靠性】這些關鍵詞進行展開。github
Promise只是一個類，爲何就可以實現異步?面試

Promise自己的確只是一個普通的類，並且在不依賴ES6的環境中，開發者甚至能夠手動實現這樣一個類，在沒有研究Promise的代碼以前，筆者一直主觀地認爲其內部是經過相似於事件監聽的機制來實現異步的，不然程序自己怎麼會知道發出的http請求何時返回結果。編程

這個問題是在筆者學習完EventLoop和Generator函數的相關知識後才理解的，其實Promise自己並無實現異步，javascript語言中的異步都是經過事件循環的機制（《javascript基礎修煉(5)——Event Loop(node.js)》）來實現的，簡單地說就是說異步事件的響應是會被事件循環不斷去主動檢測的，當異步動做知足了再次被執行的條件時（好比http請求返回告終果，或者在另外一個線程開啓的大運算量的邏輯執行完畢後返回了消息），就會被加入調用棧來執行，Promise和Generator只是配合事件循環來進行狀態管理和流程控制，它們自己和事件循環的機制是解耦的。segmentfault
Promise做爲構造函數調用而生成實例時到底發生了什麼事情？promise

這裏所指的是下面這樣的代碼：
```
promise = new Promise(function(resolve, reject){
 //....
});
```
面試中常常會問到有關Promise執行次序的問題，不少很是熟悉Promise用法的讀者也並無意識到，實際上傳入的匿名函數是會同步執行的。Promise所作的事情，是爲當前這個不知道什麼時候能完成的動做打上一些狀態的標記，並傳入兩個用於回收控制權的方法做爲參數來啓動執行這個匿名函數，經過then方法指定的後續執行邏輯會先緩存起來（這裏的描述並不嚴謹），當這個異步動做完成後調用resolve或者reject方法後，再繼續執行事先被緩存起來的流程。
Promise/A+標準看起來很複雜，該如何去實現？

Promise/A+規範的確很複雜，我也不建議你直接就經過這樣的方式來了解Promise的實現細節，【規範】意味着嚴謹性，也表示其中有不少容錯的機制，這會極大地妨礙你對Promise核心邏輯的理解，Promise代碼最大的複雜性，在於它對於鏈式調用的支持（若是不須要支持鏈式調用，你會發現本身幾乎不須要思考就能夠分分鐘擼一個Promise庫出來）。筆者的建議是先想辦法去解決主要問題，再對照Promise/A+規範去檢視本身的代碼。
Promise爲何要實現鏈式調用?

鏈式調用的實現，實現了Promise的多步驟流程控制功能，對一個多於兩個步驟的流程中，即便沒有實現鏈式調用，Promise實際上依然能夠工做，但當你真的那樣作時，你會發現它又變成了一個新的回調地獄。
Promise的可靠性是指什麼？

Promise的可靠性指它的狀態只能被改變一次，以後就不能再修改，且惟一修改它的方法是調用promise實例中的內部resolve( )或reject( )方法，它們是定義在Promise內部的，從外部沒法訪問到，只能經過Promise內部提供的機制來觸發斷定方法（new Promise(executor)生成實例時，當還行到executor時，Promise會將內部的resolve和reject方法做爲實參傳入executor，從而暴露修改自身狀態的能力），相比之下，普通對象的屬性或者thenable對象（指擁有then方法的非Promise實例對象）的屬性都是能夠被直接修改的，因此promise的狀態和結果被認爲是更可靠的。

三. 寫給小白的Promise短篇故事

假設有一個異步的動做A，還有一個但願在A完成之後執行的動做B，和一個在B完成之後去執行的動做C，咱們來看一下Promise是如何實現流程控制。

第一回狀態標記

A動做開始以前，咱們把它丟進Promise構造函數，Promise給了A一個控制器(上面有resolve和reject兩個按鈕)和一個帶有兩個抽屜的儲物櫃(onFulfilledCallbacks和onRejectedCallbacks)，接着給A交代：我已經登記好信息了，你去執行吧，等你執行完之後，若是你認爲執行成功了，就按一下控制器的resolve按鈕,若是認爲執行失敗了就按一下reject按鈕，可是你要當心，這個控制器只能用一次，按完它會自動發送消息，儲物櫃上有接收器，若是收到resolve信號，onFulfilledCallbacks這個抽屜就會打開，若是收到reject信號，onRejectedCallbacks這個抽屜就會打開，以後另外一個櫃子就會鎖死，我每隔一段時間會來查看一下你的狀態（注意這裏是在事件循環中主動輪詢來查看promise實例是否執行結束的），若是我看到你的儲物櫃有一個抽屜打開了的話的話，就會把裏面的東西拿出來依次執行接下來的事情。在這以前，若是有人想關注你的執行狀況的話，我會讓它留下兩張字條，分別寫下不一樣的抽屜打開的時須要作的事情，由於最終只有一個抽屜能夠打開，他必須得寫兩張字條，除非他只關注某個抽屜的動向，而後使用你這個儲物櫃的then方法就能夠把字條塞到對應的櫃子裏，以後等抽屜打開時，我只須要根據字條上的信息打電話給他就好了。A以爲這樣是比較穩妥的，因而拿着promise給它的控制器去執行了。

第二回回調註冊

代碼繼續執行，這時候出現了一個B，B說我得先看看A的執行結果，再決定作什麼，執行器說你也別在這乾等着了，A在咱們這裏存放了一個智能儲物櫃，它回頭會把結果遠程發送回來，你把你的聯繫方式寫在這兩張字條上，而後經過A的儲物櫃的then方法放進去吧，聯繫方式也能夠寫成不同的，到時候A返回結果的話，對應的抽屜就會打開，我按照你寫的聯繫方式發消息給你就好了。B想了想也是，因而就寫下了兩個不一樣的號碼放進了A儲物櫃對應的抽屜裏，接着就回家睡覺去了。

第三回機制缺陷

代碼繼續執行，這時候又出現了一個C，C說我想等B返回結果之後再執行，這時候執行器犯難了，B還沒出發呢，我也沒有給它分配回調儲物櫃，因此沒辦法用一樣的方式對待C，執行器只能對C說，咱們這規定若是沒有對應標記的儲物櫃的話，暫時不提供服務，這樣吧，你先把你的聯繫方式寫好交給我，等回頭若是B出發的話，我會給它分派儲物櫃，到時候把你的需求放在對應的抽屜裏，等B返回對應結果之後我再通知你，C以爲也行，因而就照作了。可是C走後，執行器就想了，要是後面再來DEF都要跟在不一樣的人後面去執行，那這些事情我都得先保管着，這也太累了，並且容易搞亂，不能這麼搞啊。

第四回流程管理

上一會講到在現有機制下缺少多步驟流程管理的機制，當異步任務A執行且沒有返回結果時，後續全部的動做都被暫存在了執行器手裏，只能隨着時間推移，當標誌性事件發生時再逐步去分發事件。爲了可以實現多步驟的流程管理，執行器想出了一個方法，爲每個來註冊後續業務邏輯的人都提供一個智能儲物櫃，這樣在辦理登記時就能夠直接將後續的方法分發到對應的抽屜裏，常見的問題就解決了。

四.鏈式調用Promise的影響

若是沒有鏈式調用，第三節中的多步驟的僞代碼多是以下的樣子：

//爲了聚焦核心邏輯，下面的僞代碼省略了onReject的回調
promiseA = new Promise(function(resolve, reject){
     //A帶着控制器開始執行
    A(resolve,reject); 
});

promiseA.then(function(resA){
    //A執行結束之後，開始判斷B究竟是否要執行
    promiseB = new Promise(function(resolveB, rejectB){
        //若是B須要執行，則分配兩個儲物櫃，並派髮狀態控制器，B帶着A返回的數據resA開始執行
        B(resA,resolveB,rejectB);
    });

    promiseB.then(function(resB){
        //B執行結束之後，開始判斷C究竟是否要執行
        promiseC = new Promise(function(resolveC, rejectC){
            //若是C須要執行，則分配兩個儲物櫃，並派髮狀態控制器，C帶着B返回的數據resB開始執行
            C(resB, resolveC, rejectC);  
        });

        //...若是有D的話
    })
});

在邏輯流程中僅僅有3個步驟的時候，回調地獄的苗頭就已經顯露無疑了。Promise被設計用來解決回調嵌套過深的問題，若是隻能按上面的方法來使用的話顯然是不能知足需求的。若是能夠支持鏈式調用，那麼上面代碼的編寫方式就變成了：

//爲了聚焦核心邏輯，下面的僞代碼省略了onReject的回調
promiseA = new Promise(function(resolve, reject){
     //A帶着控制器開始執行
    A(resolve,reject); 
});

promiseA.then(function(resA){
    //在使用then方法向A的儲物櫃裏存放事件的同時，也生成了本身的儲物櫃
    return new Promise(function(resolveB, rejectB){
         B(resA, resolveB, rejectB);
    });   
}).then(function(resB){
    return new Promise(function(resolveC, rejectC){
         C(resB, resolveC, rejectC);
    });   
}).then(function(resC){
    //若是有D動做，則繼續
})

很明顯，當流程步驟增多時，支持鏈式調用的方法具備更好的擴展性。下一節講一下Promise最關鍵的鏈式調用環節的實現。

五. Promise如何支持鏈式調用

基本原理

若是須要then方法支持鏈式調用，則Promise.prototype.then這個原型方法就須要返回一個新的promise。事實上即便在最初的時間節點上來看，後續註冊的任務也符合在將來某個不肯定的時間會返回結果的特色，只是多了一些前置條件的限制。返回新的promise實例是很是容易作到的，但從代碼編寫的邏輯來理解，這裏的promise究竟是什麼意思呢？先看一下基本實現的僞代碼：

//爲簡化核心邏輯，此處只處理Promise狀態爲PENDING的狀況
//同時也省略了容錯相關的代碼
Promise.prototype.then = function(onFulfilled, onRejected){
    let that = this;
    return new Promise(function(resolve, reject){
          //對onFulfilled方法的包裝和歸類
          that.onFulfilledCallbacks.push((value) => {
                  let x = onFulfilled(value);
                  someCheckMethod(resolve, x, ...args);
            });

         //對onRejected方法的包裝和歸類
          that.onRejectedCallbacks.push((reason) => {
              let x = onRejected(reason);
              someCheckMethod(reject, x, ...args);
          });
    });
};

能夠看到在支持鏈式調用的機制下，最終被添加至待執行隊列中的函數並非經過then方法添加進去的函數，而是經過Promise包裝爲其增長了狀態信息，而且將這個狀態改變的控制權交到了onFulfilled函數中，onFulfilled函數的返回結果，會做爲參數傳入後續的斷定函數，進而影響在執行resolve的執行邏輯，這樣就將新promise控制權暴露在了最外層。

因此，then方法中返回的promise實例，標記的就是添加進去的onFulfilled和onRejected方法的執行狀態。這裏的關鍵點在於，onFulfilled函數執行並返回結果後，纔會啓動對於這個promise的決議。

支線故事

在新的鏈式調用的支持下，上面的故事流程就發生了變化。當B前來登記事件時，執行器說咱們這如今推出了一種委託服務，你想知道那個儲物櫃的最新動態，就把你的電話寫在字條上放在對應的抽屜裏，以後當這個抽屜打開後，咱們就會把它返回的信息發送到你留在字條上的號碼上，咱們會給你提供一個智能儲物櫃（帶有this._onFulfillCallbacks抽屜和this._onRejectedCallbacks抽屜）和一個控制器，這樣別人也能夠關注你的動態，但你的控制器暫時不能用，咱們將某個消息發送到你留的手機號碼上時，纔會同步激活你的控制器功能，但它也只能做用一次。

六. resolve(promise)

再來考慮一種特殊的場景，就是當A動做調用resolve(value )方法來改變狀態機的狀態時，傳入的參數仍然是一個PENDING狀態的promise，這至關於A說本身已經完成了，可是此時卻沒法獲得執行結果，也就不可能將結果做爲參數來啓動對應的apromise._onFulfilledCallbacks隊列或者apromise_onRejectedCallbacks隊列，此時只能先等着這個promise改變狀態，而後才能執行對A動做的決議。也就是說A的決議動做要延遲到這個新的promise被決議之後。用僞代碼來表示這種狀況的處理策略就是以下的樣子：

//內部方法
let that = this;//這裏的this指向了promise實例
function resolve(result){
    if(result instanceof Promise){
        return  result.then(resolve, reject);
    }
    //執行相應的緩存隊列裏的函數
    setTimeout(() => {
        if (that.status === PENDING) {
            that.status = FULFILLED;
            that.value = result;
            that.onFulfilledCallbacks.forEach(cb => cb(that.result));
        }
    }); 
}

當前promise實例的決議經過result.then(resolve,reject)被推遲到result返回結果以後，而真正執行時所須要操做的對象和屬性，已經經過let that = this與實例進行了綁定。

不少開發者在這裏會以爲很是混亂，極可能是沒有意識到每個promise實例都會生成內部方法resolve( )和reject( )，即時當Promise類實例化的過程結束後，它們依然會被保持在本身的閉包做用域中，在執行棧中涉及到多個處於PENDING狀態的promise時，它們的內部方法都是存活的。若是仍是以爲抽象，能夠利用Chrome的調試工具，將下面的代碼逐步執行，並觀察右側調用棧，就能夠看到當傳入決議函數的是另外一個promise時，外層的決議函數都會以閉包的形式繼續存在。

let promise1 = new Promise(function(resolve, reject){
     setTimeout(function fn1(){
          let subpromise = new Promise(function (resolvesub,rejectsub) {
              setTimeout(function fn2() {
                  resolvesub('value from fn2');
              },2000);
          });
          resolve(subpromise);
     },2000);
});

promise1.then(function fn3(res) {
    console.log(res);
});

七.Promise/A+規範與造車輪指南

【Promise/A+規範】：https://github.com/promises-aplus/promises-spec

理清了上面各類狀況的基本策略後，咱們已經具有了構建一個相對完備的Promise模塊的能力。我強烈建議你按照Promise/A+規範來親自動手實現一下這個模塊，你會發如今實現的過程當中仍然有大量的代碼層面的問題須要解決，但你必定會受益於此。網上有很是多的文章講述如何根據Promise/A+標準來實現這個庫，但是在筆者看來這並非什麼值得炫耀的事情，就好像對照着攻略在打遊戲同樣。

做爲工程師，你既要可以一行一行寫出這樣一個模塊，更要關注規範爲何要那樣規定。

【Promise/A+測試套件】: https://github.com/promises-aplus/promises-tests

若是你對照規範的要求寫出了這個模塊，能夠利用官方提供的測試套件（包含800多個測試用例來測試規範中規定的各個細節）來測試本身編寫的模塊並完善它。javascript語言中都是經過鴨式辯型來檢測接口的，不管你是怎樣實現規範的各個要求，只要最終經過測試套件的要求便可。若是你依舊以爲內心沒譜，也能夠參考別人的博文來學習Promise的細節，例如這篇《Promise詳解與實現》就給了筆者很大幫助。

八.API之外的視角

當越過了語言層面的難點後，推薦你閱讀《深刻理解Promise五部曲》這個系列的文章。大多數開發者對於Promise的理解和應用都是用來解決回調地獄問題的，而這個系列的文章會讓你從另外一個角度從新認識Promise，不得不說文章中用發佈訂閱模式來類比解釋Promise的實現機制對於筆者理解Promise提供了巨大的幫助，同時它也可以引起一些經過學習promise/A+規範很難意識到的關於精髓和本質的思考。