我們知道，常見的方法呼叫都是同步呼叫，這種呼叫方式是一種阻塞式的呼叫方式，即客戶端（主呼叫方）**一直阻塞等待直到被服務端（被呼叫方）返回 為止。這種呼叫方式相對比較直觀，也是大部分程式語言直接支援的一種呼叫方式。但是，如果我們面對是基於粗粒度的服務元件，面對的是一些需要比較長時間才 能有響應的應用場景，那麼我們就需要一種非阻塞式呼叫方式，即非同步呼叫方式。
sca程式設計模式提供了三種方式的非同步呼叫，它們分別是：
1． 單向呼叫方式。
2． 延遲響應方式。
3． 請求**方式。
單向呼叫
單向呼叫方式是最為簡單的非同步呼叫方式，在這種呼叫方式中，客戶端發出請求之後就不再關心服務端的情況，包括是否執行成功，返回值是什麼等等。我們可以用下面的圖 4示來描述這種單向呼叫方式：
圖 4: 單向呼叫
單向呼叫方式是一種不管呼叫結果的方式，但是在很多情況下我們是需要知道呼叫結果的。我們需要知道呼叫是否成功，需要知道呼叫的結果，就算呼叫失敗我們也希望知道錯誤**等資訊。在這種情況下，延遲響應和請求**就是兩種能夠讓我們知道呼叫結果的方式。
延遲響應方式
延遲響應方式是指客戶端在發出呼叫請求之後繼續執行，但是經過一段時間之後，客戶端再呼叫相應的方法去檢索返回結果，並通過引數指定如何根據呼叫的 結果而執行進一步動作。由於是非同步呼叫方式，因此，在第一次發出呼叫請求的時候，服務端需要返回乙個稱為票據（ticket）的物件。這個物件會作為第二 次發出檢索結果請求時的乙個引數。顯然，這個ticket物件的作用與web程式設計的sessionid非常類似。我們可以用圖 5 來表示延遲相應呼叫方式：
圖 5：延遲響應呼叫方式
請求**
與延遲響應方式類似，請求**方式也能得到服務端的響應，但是不同的是這個響應是由服務端通過**方式來觸發的，而不像延遲響應方式由客戶端來主動 檢索的。請求**方式的原理與許多程式語言中的**機制類似，不同的是這裡實現的層次比較高一點。我們可以用圖6來表示請求呼叫方式：
圖 6：請求**方式
dubbo非同步呼叫三種方式
非同步通訊對於服務端響應時間較長的方法是必須的，能夠有效地利用客戶端的資源，在dubbo中，消費端通過 async true 標識。具體有三種方式 1 nio future主動獲取結果，返回結果放在rpccontext中 需要注意的是，由於rpccontext是單例模式，所以每次呼叫完後，需要儲存乙...
Spring中非同步呼叫的三種實現方式
設定超時時間 asynccontext.settimeout 20000 asynccontext.start new runnable catch exception e 非同步請求完成通知 此時整個請求才完成 asynccontext.complete 此時之類 request的執行緒連線已經釋...
JS非同步載入的三種方式
我們平時使用的最多的一種方式。同步模式，又稱阻塞模式，會阻止瀏覽器的後續處理，停止後續的解析，只有當當前載入完成，才能進行下一步操作。所以預設同步執行才是安全的。但這樣如果js中有輸出document內容 修改dom 重定向等行為，就會造成頁面堵塞。所以一般建議把 firefox 3.6 opera...