作者｜李茂，單位：中移物聯網有限公司

?Labs 導讀

讓我們回到三十年前所能接觸到的計算機：黑黑的屏幕上顯示著白色的文字，在文字最后閃爍著一個方塊形的光標。除專門用于對外服務的計算機外，那時候的普通使用者基本上以串行地執行指令為基礎，同一時間只運行一個應用程序，那時候的人們打字就是打字，聽歌就專門聽歌。隨著芯片制程和制造能力的提升以及圖形化操作系統在全球鋪開，我們現在通常可以一邊聽著歌，一邊玩著游戲，另一邊還從網絡上下載最新的電視劇，不僅僅如此，操作系統以及應用程序的開發者也還在極力地壓榨計算機硬件性能，使得計算機更流暢，計算機使用者同一時間可以處理更多的東西，本文將為大家帶來應用程序并發相關的知識以及基于Golang這門編程語言針對應用程序并發的相關編碼基礎。

Part 01  并發的硬件基礎

1.1 內存

作為并發編程一個基礎硬件知識儲備，首先要說的就是內存了，對于內存芯片網上喜歡將其表述為內存顆粒，是一堆MOS管的集合，在半導體稱呼里面，很多MOS管組成一個半導體組（module），很多個module組成一個管芯（die），這個die即是內存顆粒，當然，更上一級即很多die組成的東西叫做晶圓（wafer）。

簡單來說，每8個MOS管組成的電路可以表示一個字節，比如ASCII的‘A’，我們使用65表示，即0100 0001，那么8個MOS分別使用低-高-低-低-低-低-低-高電位即可表示字符A。

在對內存的寫入和讀取時，通常也是按照8個字開始作為一組進行操作，我們現在常用的CPU是64位，可以一次性處理64/8=8個字節的數據。

1.2 總線

總線的概念同我們高速公路的概念類似，就像京滬高速的存在不僅僅只是用于北京和上海之間的交通通勤，只要目的地是那個地理區間的車輛都可以行駛進入京滬高速，從而提升車輛速度節省時間。總線是計算機各種功能部件之間傳送信息的公共通信干線，按照分類又地址總線、數據總線、控制總線等，他們分辨用來傳輸數據地址、輸出以及控制信號，它是計算機中用于傳遞信息的公用通道。

一個CPU要操作內存的數據，也是通過總線來進行操作的。通常來說內存的讀寫操作不是一個CPU指令周期能完成的，在這期間如果多個程序在同時操作一個內存地址，則有各種意外的讀寫操作。

1.3 CPU

在單核CPU時期，硬件一次只能處理一個事情，在多任務的情況下不同的任務按需搶占CPU來執行它的代碼，這里面就涉及到CPU調度工作，通常情況下，操作系統已經幫我們做了很多事，如果一個編程語言開啟的并發操作是交給了操作系統的，那么調度這塊不需要太關心，如果像Golang這樣有自己的協程調度器，還是需要專門了解下特有的調度方式。對于多核處理器基本原理也差不多，在對于硬件的理解上也可以完全參考單核。

CPU通過地址總線去尋找內存地址,比如0x00004567這種，64位CPU最大能操作的地址長度為264，32位操作系統則是232，所以為什么32位CPU最大只支持4GB內存呢？來算一算232是多少（友情提示1GB=1024MB=1024*1024KB=1024*1024*1024B）。

Part 02  并發的軟件基礎

2.1 多進程模型

多進程模型是操作系統層面進行并發的最基本模型，要理解它也較為簡單，比如我們需要聽歌便打開了音樂播放器，我們想玩游戲便打開了游戲用用程序，音樂播放器、游戲程序便是一個個進程，我們可以在計算機里讓專門的進程負責播放聲音，讓專門的進程負責網絡連接，讓專門的進程展現游戲畫面，讓每個進程做自己專注的事情，互不影響，這樣做的壞處便是系統開銷是最大的，所有的進程都由操作系統進行管理。

2.2 多線程模型

同多進程模型一樣，多線程模型在操作系統看來也屬于系統層面的并發模式，到目前為止也是程序員們使用最多的一種，就像我們的音樂播放器本職工作是播放音樂，在播放音樂的同時會搜索當前歌曲的歌詞并通過網絡下載到計算機上，而搜索歌詞并下載這塊功能則是通過音樂播放器進程生成一個歌詞處理線程進行處理。對于線程模型的理解可以同理解進程模型一樣，每個線程也可以專注做自己的事情互不影響，這種模型的好處是系統開銷比多進程模型要小一些，但是線程過多也會對操作系統有影響。

2.3 異步IO模型

這種模型的誕生源于多進程、多線程導致系統資源快速耗盡的危機，異步IO顧名思義即不會按照順序一步一步地做事情，在某些比較耗時的事情的上時候應用的進程/線程不會去等待，而是直接執行后面的步驟，直到比較耗時的事情做完了再通知到進程/線程。這種模型的優勢是可以開辟少量的線程做更多的事情，但是缺點也顯而易見，由于整個應用程序的執行流程上被打散，程序員需要通過更多精力處理這種散亂的執行狀態。

2.4 協程模型

協程本質上是一種由進程自身管理的線程，這種線程不交給操作系統進行管理，但是本身又真實地寄存在操作系統的線程中，系統開銷極小，也避免了異步IO的散亂缺點，目前的缺點是支持這種模型的編程語言很少，存在比較早的，被大眾所使用的一些編程語言因為各自的歷史原因目前都沒有大規模地針對這種模型進行適配，有一門比較新的編程語言——Golang對于該模型的支持還算不錯。接下來我們就通過Golang的幾個示例代碼來看看并發編程一些具體操作。

Part 03  幾個代碼示例

示例一

//非并發方式計算變量A從0開始累加100次，最后輸出結果

示例二

//變量A從0開始累加100次，每次都由單獨的協程并發進行加法操作，最后輸出結果

示例一個示例二都將輸出什么呢：絕大多數情況下都是100。

按照正常的理解，示例二不應是1-100之間的任意數字嗎，難不成go的協程還自動處理了變量搶占等一系列問題，從而使我們就完全很開心地編碼了？實際上先把示例二的100改成10000再看看結果吧~

我們再看看示例三和示例四：

示例三

//非并發方式輸出變量i從0-10000每次加1的循環結果

示例四

//多協程方式輸出變量i從0-10000每次加1的循環結果

示例三是中規中矩的單協程模型，輸出也不會有什么意外，而示例四大家猜猜是按照1,2,3...9999這樣的順序呢還是其他順序輸出呢？

如果實驗了我們便能較為容易地得出結果，多協程模型里面的東西沒有順序性，對變量的操作也沒有原子性，和多線程模型處理東西的方式幾乎一樣。

有些場景下為了保證應用程序執行有序，我們通常采用加鎖的方式進行處理，如示例五。

示例五

//多協程加鎖處理使之有序：

搬磚例子

假設在左邊有三堆散亂的磚，我們需要將其從左邊搬運到右邊并堆放整齊，這樣的一個工作我們從并發模型來看有哪些比較可執行的實現方式呢：

1. 每堆磚頭分配固定的人數，堆磚時為保證堆疊整齊度，采用排隊的方式一個一個按先后順序堆疊
2. 拿一個人專職在左邊遞磚，若干人從左邊的遞磚人處拿磚，搬磚后在右邊排隊堆疊
3. 左邊專人遞磚，右邊專人堆磚，若干搬磚人只負責搬磚

這也是并發編程模型中比較常用的編程思路，在以后遇到類似開發場景也可以套用這些例子。

一個實際案例

我們以一個實際的案例作為結束，這個案例是導出某云平臺所屬設備信息的代碼，里面包含有多協程拉取數據的實例，整體的流程如下：

1. 參數初始化
2. 定義一個接收協程結束的信息通道
3. 開啟N個協程
4. 協程調用API獲取信息，按分頁參數每個協程獲取（總數/N）信息，每次page=X+N
5. 每次獲取的信息放入excel緩沖區
6. 當最后的分頁獲取不到信息時向通道寫入東西表示該協程任務完成
7. 主進程循環獲取每個協程結束的信息，直到所有協程任務完成
8. 將excel緩沖區數據寫入excel文件
9. 結束

案例鏈接如下（cm-heclouds為物聯網公司平臺部存放開源代碼的專用賬戶）：

https://github.com/cm-heclouds/onenet_device_export/releases/tag/2018-latest

當然，這個案例在并發上其實還存在較大的提升空間，聰明的大家看看結合搬磚的例子來怎么提升呢。?