承接上文《終于明白了，一文徹底理解I/O多路復(fù)用》。在這篇文章中我們來(lái)討論一下到底什么是同步，什么是異步，以及在編程中這兩個(gè)極為重要的概念到底意味著什么。

相信很多同學(xué)遇到同步異步這兩個(gè)詞的時(shí)候大腦瞬間就像紅綠燈失靈的十字路口一樣陷入一片懵逼的狀態(tài)：是的，這兩個(gè)看上去很像實(shí)際上也很像的詞匯給博主造成過(guò)很大的困擾，這兩個(gè)詞背后所代表的含義到底是什么呢？

我們先從工作場(chǎng)景講起。

苦逼程序員

假設(shè)現(xiàn)在老板分配給了你一個(gè)很緊急并且很重要的任務(wù)，讓你下班前必須完成（萬(wàn)惡的資本主義）。為了督促進(jìn)度，老板搬了個(gè)椅子坐在一邊盯著你寫代碼。 你心里肯定已經(jīng)罵上了，“WTF，你有這么閑嗎？盯著老子，你就不能去干點(diǎn)其他事情嗎？” 老板仿佛接收到了你的腦電波一樣：“我就在這等著，你寫完前我哪也不去，廁所也不去?！?/p>

這個(gè)例子中老板交給你任務(wù)后就一直等待，什么都不做直到你寫完，這個(gè)場(chǎng)景就是所謂的同步。

第二天，老板又交給了你一項(xiàng)任務(wù)。

不過(guò)這次就沒(méi)那么著急啦，這次老板輕描淡寫，“小伙子可以啊，不錯(cuò)不錯(cuò)，你再努力干一年，明年我就財(cái)務(wù)自由了，今天的這個(gè)任務(wù)不著急，你寫完告訴我一聲就行”。

這次老板沒(méi)有盯著你寫代碼，而是轉(zhuǎn)身刷視頻去了，你寫完后簡(jiǎn)單的和老板報(bào)告一聲“我寫完了”。

在這個(gè)例子中老板交代完任務(wù)后不再一直等著什么都不做而是就去忙其它事情，你完成任務(wù)后簡(jiǎn)單的告訴老板任務(wù)完成，這就是所謂的異步。

值得注意的是，在異步這種場(chǎng)景下重點(diǎn)是在你寫代碼的同時(shí)老板在刷劇，這兩件事在同時(shí)進(jìn)行，而不是一方等待另一方，因此這就是為什么一般來(lái)說(shuō)異步比同步高效的本質(zhì)所在，不管同步異步應(yīng)用在什么場(chǎng)景下。

我們可以看到同步這個(gè)詞往往和任務(wù)的“依賴”、“關(guān)聯(lián)”、“等待”等關(guān)鍵詞相關(guān)，而異步往往和任務(wù)的“不依賴”，“無(wú)關(guān)聯(lián)”，“無(wú)需等待”，“同時(shí)發(fā)生”等關(guān)鍵詞相關(guān)。

By the way，如果遇到一個(gè)在身后盯著你寫代碼的老板，三十六計(jì)走為上策。

打電話與發(fā)郵件

作為一名苦逼的程序員是不能只顧埋頭搬磚的，平時(shí)工作中的溝通免除不了，其中一種高效的溝通方式是吵架。。。啊不，是電話。

通常打電話時(shí)都是一個(gè)人在說(shuō)另一個(gè)人聽，一個(gè)人在說(shuō)的時(shí)候另一個(gè)人等待，等另一個(gè)人說(shuō)完后再接著說(shuō)，因此在這個(gè)場(chǎng)景中你可以看到，“依賴”、“關(guān)聯(lián)”、“等待”這些關(guān)鍵詞出現(xiàn)了，因此打電話這種溝通方式就是所謂的同步。

另一種碼農(nóng)常用的溝通方式是郵件。

郵件是另一種必不可少溝通方式，因?yàn)闆](méi)有人傻等著你寫郵件什么都不做，因此你可以慢慢悠悠的寫，當(dāng)你在寫郵件時(shí)收件人可以去做一些像摸摸魚啊、上個(gè)廁所、和同時(shí)抱怨一下為什么十一假期不放兩周之類有意義的事情。

同時(shí)當(dāng)你寫完郵件發(fā)出去后也不需要干巴巴的等著對(duì)方回復(fù)什么都不做，你也可以做一些像摸魚之類這樣有意義的事情。

在這里，你寫郵件別人摸魚，這兩件事又在同時(shí)進(jìn)行，收件人和發(fā)件人都不需要相互等待，發(fā)件人寫完郵件的時(shí)候簡(jiǎn)單的點(diǎn)個(gè)發(fā)送就可以了，收件人收到后就可以閱讀啦，收件人和發(fā)件人不需要相互依賴、不需要相互等待。

你看，在這個(gè)場(chǎng)景下“不依賴”，“無(wú)關(guān)聯(lián)”，“無(wú)需等待”這些關(guān)鍵詞就出現(xiàn)了，因此郵件這種溝通方式就是異步的。

同步調(diào)用

現(xiàn)在終于回到編程的主題啦。

既然現(xiàn)在我們已經(jīng)理解了同步與異步在各種場(chǎng)景下的意義（I hope so），那么對(duì)于程序員來(lái)說(shuō)該怎樣理解同步與異步呢？

我們先說(shuō)同步調(diào)用，這是程序員最熟悉的場(chǎng)景。

一般的函數(shù)調(diào)用都是同步的，就像這樣：

funcA（） { // 等待函數(shù)funcB執(zhí)行完成 funcB（）; // 繼續(xù)接下來(lái)的流程}

funcA調(diào)用funcB，那么在funcB執(zhí)行完前，funcA中的后續(xù)代碼都不會(huì)被執(zhí)行，也就是說(shuō)funcA必須等待funcB執(zhí)行完成，就像這樣：

從上圖中我們可以看到，在funcB運(yùn)行期間funcA什么都做不了，這就是典型的同步。

注意，一般來(lái)說(shuō)，像這種同步調(diào)用，funcA和funcB是運(yùn)行在同一個(gè)線程中的，這是最為常見的情況。

但值得注意的是，即使運(yùn)行在兩個(gè)不能線程中的函數(shù)也可以進(jìn)行同步調(diào)用，像我們進(jìn)行IO操作時(shí)實(shí)際上底層是通過(guò)系統(tǒng)調(diào)用（關(guān)于系統(tǒng)調(diào)用請(qǐng)參考《程序員應(yīng)如何理解系統(tǒng)調(diào)用》）的方式向操作系統(tǒng)發(fā)出請(qǐng)求的，比如磁盤文件讀?。?/p>

read（file， buf）;

這就是我們?cè)凇蹲x取文件時(shí)，程序經(jīng)歷了什么》中描述的阻塞式I/O，在read函數(shù)返回前程序是無(wú)法繼續(xù)向前推進(jìn)的

read（file， buf）;// 程序暫停運(yùn)行，// 等待文件讀取完成后繼續(xù)運(yùn)行

如圖所示：

只有當(dāng)read函數(shù)返回后程序才可以被繼續(xù)執(zhí)行。

注意，和上面的同步調(diào)用不同的是，函數(shù)和被調(diào)函數(shù)運(yùn)行在不同的線程中。

因此我們可以得出結(jié)論，同步調(diào)用和函數(shù)與被調(diào)函數(shù)是否運(yùn)行在同一個(gè)線程是沒(méi)有關(guān)系的。

在這里我們還要再次強(qiáng)調(diào)，同步方式下函數(shù)和被調(diào)函數(shù)無(wú)法同時(shí)進(jìn)行。

同步編程對(duì)程序員來(lái)說(shuō)是最自然最容易理解的。

但容易理解的代價(jià)就是在一些場(chǎng)景下，同步并不是高效的，原因很簡(jiǎn)單，因?yàn)槿蝿?wù)沒(méi)有辦法同時(shí)進(jìn)行。

接下來(lái)我們看異步調(diào)用。

異步調(diào)用

有同步調(diào)用就有異步調(diào)用。

如果你真的理解了本節(jié)到目前為止的內(nèi)容的話，那么異步調(diào)用對(duì)你來(lái)說(shuō)不是問(wèn)題。

一般來(lái)說(shuō)，異步調(diào)用總是和I/O操作等耗時(shí)較高的任務(wù)如影隨形，像磁盤文件讀寫、網(wǎng)絡(luò)數(shù)據(jù)的收發(fā)、數(shù)據(jù)庫(kù)操作等。

我們還是以磁盤文件讀取為例。

在read函數(shù)的同步調(diào)用方式下，文件讀取完之前調(diào)用方是無(wú)法繼續(xù)向前推進(jìn)的，但如果read函數(shù)可以異步調(diào)用情況就不一樣了。

假如read函數(shù)可以異步調(diào)用的話，即使文件還沒(méi)有讀取完成，read函數(shù)也可以立即返回。

read（file， buff）;// read函數(shù)立即返回// 不會(huì)阻塞當(dāng)前程序

就像這樣：

可以看到，在異步這種調(diào)用方式下，調(diào)用方不會(huì)被阻塞，函數(shù)調(diào)用完成后可以立即執(zhí)行接下來(lái)的程序。

這時(shí)異步的重點(diǎn)就在于調(diào)用方接下來(lái)的程序執(zhí)行可以和文件讀取同時(shí)進(jìn)行，從上圖中我們也能看出這一點(diǎn)，這就是異步的高效之處。

但是，請(qǐng)注意，異步調(diào)用對(duì)于程序員來(lái)說(shuō)在理解上是一種負(fù)擔(dān)，代碼編寫上更是一種負(fù)擔(dān)，總的來(lái)說(shuō)，上帝在為你打開一扇門的時(shí)候會(huì)適當(dāng)?shù)年P(guān)上一扇窗戶。

有的同學(xué)可能會(huì)問(wèn)，在同步調(diào)用下，調(diào)用方不再繼續(xù)執(zhí)行而是暫停等待，被調(diào)函數(shù)執(zhí)行完后很自然的就是調(diào)用方繼續(xù)執(zhí)行，那么異步調(diào)用下調(diào)用方怎知道被調(diào)函數(shù)是否執(zhí)行完成呢？

這就分為了兩種情況：

調(diào)用方根本就不關(guān)心執(zhí)行結(jié)果

調(diào)用方需要知道執(zhí)行結(jié)果

第一種情況比較簡(jiǎn)單，無(wú)需討論。

第二種情況下就比較有趣了，通常有兩種實(shí)現(xiàn)方式：

一種是通知機(jī)制，也就是說(shuō)當(dāng)任務(wù)執(zhí)行完成后發(fā)送信號(hào)來(lái)通知調(diào)用方任務(wù)完成，注意這里的信號(hào)有很多實(shí)現(xiàn)方式，Linux中的signal，或者使用信號(hào)量等機(jī)制都可以實(shí)現(xiàn)。

另一種是就是回調(diào)，也就是我們常說(shuō)的callback，關(guān)于回調(diào)我們將在下一篇文章中重點(diǎn)講解，本篇會(huì)有簡(jiǎn)短的討論。

接下來(lái)我們用一個(gè)具體的例子講解一下同步調(diào)用與異步調(diào)用。

同步 VS 異步

我們以常見的Web服務(wù)來(lái)舉例說(shuō)明這一問(wèn)題。

一般來(lái)說(shuō)Web Server接收到用戶請(qǐng)求后會(huì)有一些典型的處理邏輯，最常見的就是數(shù)據(jù)庫(kù)查詢（當(dāng)然，你也可以把這里的數(shù)據(jù)庫(kù)查詢換成其它I/O操作，比如磁盤讀取、網(wǎng)絡(luò)通信等），在這里我們假定處理一次用戶請(qǐng)求需要經(jīng)過(guò)步驟A、B、C，然后讀取數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)讀取完成后需要經(jīng)過(guò)步驟D、E、F，就像這樣：

# 處理一次用戶請(qǐng)求需要經(jīng)過(guò)的步驟：A;B;C;數(shù)據(jù)庫(kù)讀取;D；E；F；

其中步驟A、B、C和D、E、F不需要任何I/O，也就是說(shuō)這六個(gè)步驟不需要讀取文件、網(wǎng)絡(luò)通信等，涉及到I/O操作的只有數(shù)據(jù)庫(kù)查詢這一步。

一般來(lái)說(shuō)這樣的Web Server有兩個(gè)典型的線程：主線程和數(shù)據(jù)庫(kù)處理線程，注意，這討論的只是典型的場(chǎng)景，具體業(yè)務(wù)實(shí)際上可會(huì)有差別，但這并不影響我們用兩個(gè)線程來(lái)說(shuō)明問(wèn)題。

首先我們來(lái)看下最簡(jiǎn)單的實(shí)現(xiàn)方式，也就是同步。

這種方式最為自然也最為容易理解：

// 主線程main_thread（） { A; B; C; 發(fā)送數(shù)據(jù)庫(kù)查詢請(qǐng)求; D; E; F;}// 數(shù)據(jù)庫(kù)線程DataBase_thread（） { while（1） { 處理數(shù)據(jù)庫(kù)讀取請(qǐng)求; 返回結(jié)果; }}

這就是最為典型的同步方法，主線程在發(fā)出數(shù)據(jù)庫(kù)查詢請(qǐng)求后就會(huì)被阻塞而暫停運(yùn)行，直到數(shù)據(jù)庫(kù)查詢完畢后面的D、E、F才可以繼續(xù)運(yùn)行，就像這樣：

從圖中我們可以看到，主線程中會(huì)有“空隙”，這個(gè)空隙就是主線程的“休閑時(shí)光”，主線程在這段休閑時(shí)光中需要等待數(shù)據(jù)庫(kù)查詢完成才能繼續(xù)后續(xù)處理流程。

在這里主線程就好比監(jiān)工的老板，數(shù)據(jù)庫(kù)線程就好比苦逼搬磚的程序員，在搬完磚前老板什么都不做只是緊緊的盯著你，等你搬完磚后才去忙其它事情。

顯然，高效的程序員是不能容忍主線程偷懶的。

是時(shí)候祭出大殺器了，這就是異步。

在異步這種實(shí)現(xiàn)方案下主線程根本不去等待數(shù)據(jù)庫(kù)是否查詢完成，而是發(fā)送完數(shù)據(jù)庫(kù)讀寫請(qǐng)求后直接處理下一個(gè)請(qǐng)求。

有的同學(xué)可能會(huì)有疑問(wèn)，一個(gè)請(qǐng)求需要經(jīng)過(guò)A、B、C、數(shù)據(jù)庫(kù)查詢、D、E、F這七個(gè)步驟，如果主線程在完成A、B、C、數(shù)據(jù)庫(kù)查詢后直接進(jìn)行處理接下來(lái)的請(qǐng)求，那么上一個(gè)請(qǐng)求中剩下的D、E、F幾個(gè)步驟怎么辦呢？

如果大家還沒(méi)有忘記上一小節(jié)內(nèi)容的話應(yīng)該知道，這有兩種情況，我們來(lái)分別討論。

1，主線程不關(guān)心數(shù)據(jù)庫(kù)操作結(jié)果

在這種情況下，主線程根本就不關(guān)心數(shù)據(jù)庫(kù)是否查詢完畢，數(shù)據(jù)庫(kù)查詢完畢后自行處理接下來(lái)的D、E、F三個(gè)步驟，就像這樣：

看到了吧，接下來(lái)重點(diǎn)來(lái)了哦。

我們說(shuō)過(guò)一個(gè)請(qǐng)求需要經(jīng)過(guò)七個(gè)步驟，其中前三個(gè)是在主線程中完成的，后四個(gè)是在數(shù)據(jù)庫(kù)線程中完成的，那么數(shù)據(jù)庫(kù)線程是怎么知道查完數(shù)據(jù)庫(kù)后要處理D、E、F這幾個(gè)步驟呢？

這時(shí)，我們的另一個(gè)主角回調(diào)函數(shù)就開始登場(chǎng)啦。

沒(méi)錯(cuò)，回調(diào)函數(shù)就是用來(lái)解決這一問(wèn)題的。

我們可以將處理D、E、F這幾個(gè)步驟封裝到一個(gè)函數(shù)中，假定將該函數(shù)命名為handle_DEF_after_DB_query：

void handle_DEF_after_DB_query （） { D; E; F;}

這樣主線程在發(fā)送數(shù)據(jù)庫(kù)查詢請(qǐng)求的同時(shí)將該函數(shù)一并當(dāng)做參數(shù)傳遞過(guò)去：

DB_query（request， handle_DEF_after_DB_query）;

數(shù)據(jù)庫(kù)線程處理完后直接調(diào)用handle_DEF_after_DB_query就可以了，這就是回調(diào)函數(shù)的作用。

也有的同學(xué)可能會(huì)有疑問(wèn)，為什么這個(gè)函數(shù)要傳遞給數(shù)據(jù)庫(kù)線程而不是數(shù)據(jù)庫(kù)線程自己定義自己調(diào)用呢？

因?yàn)閺能浖M織結(jié)構(gòu)上講，這不是數(shù)據(jù)庫(kù)線程該做的工作。

數(shù)據(jù)庫(kù)線程需要做的僅僅就是查詢數(shù)據(jù)庫(kù)、然后調(diào)用一個(gè)處理函數(shù)，至于這個(gè)處理函數(shù)做了些什么數(shù)據(jù)庫(kù)線程根本就不關(guān)心，也不應(yīng)該關(guān)心。

你可以傳入各種各樣的回調(diào)函數(shù)。也就是說(shuō)數(shù)據(jù)庫(kù)系統(tǒng)可以針對(duì)回調(diào)函數(shù)這一抽象的函數(shù)變量來(lái)編程，從而更好的應(yīng)對(duì)變化，因?yàn)榛卣{(diào)函數(shù)的內(nèi)容改變不會(huì)影響到數(shù)據(jù)庫(kù)線程的邏輯，而如果數(shù)據(jù)庫(kù)線程自己定義處理函數(shù)那么這種設(shè)計(jì)就沒(méi)有靈活性可言了。

而從軟件開發(fā)的角度看，假設(shè)數(shù)據(jù)庫(kù)線程邏輯封裝為了庫(kù)提供給其它團(tuán)隊(duì)，當(dāng)數(shù)據(jù)庫(kù)團(tuán)隊(duì)在研發(fā)時(shí)怎么可能知道數(shù)據(jù)庫(kù)查詢后該做什么呢？

顯然，只有使用方才知道查詢完數(shù)據(jù)庫(kù)后該做些什么，因此使用方在使用時(shí)簡(jiǎn)單的傳入這個(gè)回調(diào)函數(shù)就可以了。

這樣復(fù)雜數(shù)據(jù)庫(kù)的團(tuán)隊(duì)就和使用方團(tuán)隊(duì)實(shí)現(xiàn)了所謂的解耦。

現(xiàn)在你應(yīng)該明白回調(diào)函數(shù)的作用了吧。

如果你覺(jué)得有幫到你，請(qǐng)伸出你的小手幫忙分享再看一下，原創(chuàng)不易，你的一個(gè)在看是對(duì)博主最大的肯定，拜托大家啦。

不容易啊，容我喝口水叉會(huì)兒腰歇一歇。

我們繼續(xù)。

另外仔細(xì)觀察上面兩張圖，你能看出為什么異步比同步高效嗎？

原因很簡(jiǎn)單，這也是我們?cè)诒酒岬竭^(guò)的，異步天然就無(wú)需等待，無(wú)依賴。

從上一張圖中我們可以看到主線程的“休閑時(shí)光”不見了，取而代之的是不斷的工作、工作、工作，就像苦逼的996程序員一樣，而且數(shù)據(jù)庫(kù)線程也沒(méi)有那么大段大段的空閑了，取而代之的也是工作、工作、工作。

主線程處理請(qǐng)求和數(shù)據(jù)庫(kù)處理查詢請(qǐng)求可以同時(shí)進(jìn)行，因此從系統(tǒng)性能上看，這樣的設(shè)計(jì)能更加充分的利用系統(tǒng)資源，更加快速的處理請(qǐng)求；從用戶的角度看，系統(tǒng)的響應(yīng)也會(huì)更加迅速。

這就是異步的高效之處。

但我們應(yīng)該也可以看出，異步編程并不如同步來(lái)的容易理解，系統(tǒng)可維護(hù)性上也不如同步模式。

那么有沒(méi)有一種方法既能結(jié)合同步模式的容易理解又能結(jié)合異步模式的高效呢？答案是肯定的，我們將在后續(xù)章節(jié)詳細(xì)講解這一技術(shù)。

接下來(lái)我們看第二種情況，那就是主線程需要關(guān)心數(shù)據(jù)庫(kù)查詢結(jié)果。

2. 主線程關(guān)心數(shù)據(jù)庫(kù)操作結(jié)果

在這種情況下，數(shù)據(jù)庫(kù)線程需要將查詢結(jié)果利用通知機(jī)制發(fā)送給主線程，主線程在接收到消息后繼續(xù)處理上一個(gè)請(qǐng)求的后半部分，就像這樣：

從這里我們可以看到，ABCDEF幾個(gè)步驟全部在主線中處理，同時(shí)主線程同樣也沒(méi)有了“休閑時(shí)光”，只不過(guò)在這種情況下數(shù)據(jù)庫(kù)線程是比較清閑的，從這里并沒(méi)有上一種方法高效，但是依然要比同步模式下要高效。

最后需要注意的是，并不是所有的情況下異步都一定比同步高效，還需要結(jié)合具體業(yè)務(wù)以及IO的復(fù)雜度具體情況具體分析。

總結(jié)

在這篇文章中我們從各種場(chǎng)景分析了同步與異步這兩個(gè)概念，但是不管在什么場(chǎng)景下，同步往往意味著雙方要相互等待、相互依賴，而異步意味著雙方相互獨(dú)立、各行其是。希望本篇能對(duì)大家理解這兩個(gè)重要的概念有所幫助。

原文標(biāo)題：從小白到高手，你需要理解同步與異步（內(nèi)含10張圖）

文章出處：【微信公眾號(hào)：玩轉(zhuǎn)單片機(jī)】歡迎添加關(guān)注！文章轉(zhuǎn)載請(qǐng)注明出處。

責(zé)任編輯：haq