程式員修神之路–問世間非同步為何物？

關於非同步的定義，網上有很多不同的形式，但是歸根結底中心思想是不變的。無論是在http請求呼叫的層面，還是在cpu核心態和使用者態傳輸資料的層面，非同步這個行為針對的是呼叫方：

在多數程式員的概念中一般是指執行緒處理的層面：

可以這樣通俗的理解，非同步主要解決的問題是不阻塞呼叫方，用方這裡可以是http請求的發起者，也可以是一個執行緒。

但此處需要明確的是:非同步與多執行緒與並行不是同一個概念。

我聽有的同學說，非同步解決的是IO密集型的操作，菜菜覺得是不準確的。非同步同樣可以解決CPU密集型操作，只不過場景有限而已。有一個前提：利用非同步解決CPU密集型操作要求當前執行環境支援多執行緒才行，比如javascript這個語言，本質上它的執行環境是單執行緒的，所以對於CPU密集型操作，javascript會顯得力不從心。

非同步解決CPU密集操作一般情況下發生在同行程中，為什麼這麼說呢，如果發生在不同機器或者不同行程在很多情況下已經屬於IO密集型的範圍了。這裡順便提醒一下：IO操作可不單單是指磁碟的操作，所有有輸入/輸出(Input/Output)操作的都可以泛稱為IO。

舉個慄子吧：

在一個帶有UI的軟體上點選一個按鈕，UI執行緒會發生操作行為，假如UI執行緒在執行過程中有一個計算比較耗時的操作（你可以想象成計算1–999999999的和），UI執行緒在同步操作的情況下會一直等待計算結果，在計算完畢之後才會繼續執行剩餘操作，在等待的這個過程中，呈現給使用者的情況就是UI卡住了，俗稱假死了，帶給使用者的體驗是非常不好的。這種情況下，我們可以新啟動一個執行緒去執行這個耗時的操作，當執行完畢，利用某種通知機制來通知原來執行緒，以便原來執行緒繼續自己的操作。

非同步的優勢在IO密集型操作中表現的淋漓盡致，無論是讀取一個檔案還是發起一個網路請求，菜菜的建議是儘量使用非同步。這裡首先普及一個小知識：其實每個外設裝置都有自己的處理器，比如磁碟，所以每個外設裝置都可以處理自己相應的請求操作。但是處理外設裝置資訊的速度和cpu的執行速度來比較有著天壤之別。

上圖展示了不同的 IO 操作所佔用的 CPU 時鐘週期，在計算機中，CPU 的運算速度最快，以其的運算速度為基準，時鐘週期為1。其次是一級快取、二級快取和記憶體，硬碟和網路最慢，它們所花費的時鐘週期和記憶體所花費的時鐘週期差距在五位數以上，更不用提跟 CPU 和一級快取、二級快取的差距了。

由於速度的差距，所以幾乎所有的IO操作都推薦使用非同步。比如當讀取磁碟一個檔案的時候，同步狀態下當前執行緒在等待讀取的結果，這個執行緒閑置的時間幾乎可以用蛋疼來形容。所以現代的幾乎所有的知名第三方的操作都是非同步操作，尤其以Redis，Nodejs 為代表的單執行緒執行環境令人刮目相看。

現在是微服務盛行的時代，UI往往一個簡單的按鈕操作，其實在後臺程式可能呼叫了幾個甚至更多的微服務介面（關於微服務這裡不展開），如果程式是同步操作的話，那響應時間是這些服務介面響應時間的和，但是如果採用的是非同步操作，呼叫方可以在瞬間把呼叫服務介面的操作發送出去，執行緒可以繼續執行下邊程式碼或者等待所有的服務介面傳回值也可以。最差的情況下，介面的響應時間為最慢的那個服務介面響應時間，這有點類似於木桶效應。

透過以上介紹，我們一定要記住一個知識點：非同步需要回呼機制。非同步操作之所以能在執行結果完成之後繼續執行下麵程式完全歸功於回呼，這也是所有非同步場景的核心所在，前到js的非同步回呼，後到cpu核心空間copy資料到使用者空間完成通知 等等非同步場景，回呼無處不在。說道回呼大部分語言都是註冊一個回呼函式，比如js會把回呼的方法註冊到執行的佇列，c#會把回呼註冊到IOCP。這裡延伸一下，在很多系統裡，很多IO網路模型其實是屬於同步範疇的，比如多路復用技術，真正非同步非阻塞的推薦windows下的IOCP。

現在很多現代語言都支援更優秀的回呼方式，比如js和c# 現在都支援async 和await方式來進行非同步操作。

優勢

劣勢