GO協程

首先得瞭解作業系統是怎麼玩線程的。一個線程就是一個棧加一堆資源。作業系統一會讓cpu跑線程A，一會讓cpu跑線程B，靠A和B的棧來儲存A和B的執行狀態。每個線程都有他自己的棧。

但是線程又老貴了，花不起那個錢，所以go發明了goroutine。大致就是說給每個goroutine弄一個分配在heap裡面的棧來類比線程棧。比方說有3個goroutine，A,B,C，就在heap上弄三個棧出來。然後Go讓一個單線程的scheduler開始跑他們仨。相當於 { A(); B(); C() }，連續的，串列的跑。
和作業系統不太一樣的是，作業系統可以隨時隨地把你線程停掉，切換到另一個線程。這個單線程的scheduler沒那個能力啊，他就是user space的一段樸素的代碼，他跑著A的時候控制權是在A的代碼裡面的。A自己不退出誰也沒辦法。
所以A跑一小段後需要主動說，老大（scheduler），我不想跑了，幫我把我的所有的狀態儲存在我自己的棧上面，讓我歇一會吧。這時候你可以看做A返回了。A返回了B就可以跑了，然後B跑一小段說，跑夠了，儲存狀態，返回，然後C再跑。C跑一段也返回了。
這樣跑完{A(); B(); C()}之後，我們發現，好像他們都只跑了一小段啊。所以外面要包一個迴圈，大致是： 

goroutine_list = [A, B, C]while(goroutine):  for goroutine in goroutine_list:    r = goroutine()    if r.finished():      goroutine_list.remove(r)

比如跑完一圈A，B，C之後誰也沒執行完，那麼就在回到A執行一次。由於我們把A的棧儲存在了HEAP裡，這時候可以把A的棧複製粘貼會系統棧裡（我很確定真實情況不是這麼玩的，會意就行），然後再調用A，這時候由於A是跑到一半自己說跳出來的，所以會從剛剛跳出來的地方繼續執行。比如A的內部大致上是這樣

def A:  上次跑到的地方 = 找到上次跑哪兒了  讀取所有臨時變數  goto 上次跑到的地方  a = 1  print("do something")  go.scheduler.儲存程式指標 // 設定"這次跑哪兒了"  go.scheduler.儲存臨時變數們  go.scheduler.跑夠了_換人 //相當於return  print("do something again")  print(a)

第一次跑A，由於這是第一次，會列印do something，然後儲存臨時變數a，並儲存跑到的地方，然後返回。再跑一次A，他會找到上次返回的地方的下一句，然後恢複臨時變數a，然後接著跑，會列印“do something again"和1

所以你看出來了，這個關鍵就在於每個goroutine跑一跑就要讓一讓。一般支援這種玩意（叫做coroutine）的語言都是讓每個coroutine自己說，我跑夠了，換人。goroutine比較文藝的地方就在於，他可以來幫你判斷啥時候“跑夠了”。

其中有一大半就是靠的你說的“非同步並發”。go把每一個能非同步並發的操作，像你說的檔案訪問啦，網路訪問啦之類的都包包好，包成一個看似樸素的而且是同步的“方法”，比如string readFile（我瞎舉得例子）。但是神奇的地方在於，這個方法裡其實會調用“非同步並發”的操作，比如某作業系統提供的asyncReadFile。你也知道，這種非同步方法呼叫都是很快返回的。
所以你自己在某個goroutine裡寫了

string s = go.file.readFile("/root")

其實go偷偷在裡面執行了某作業系統的API asyncReadFIle。跑起來之後呢，這個方法就會說，我當前所在的goroutine跑夠啦，把剛剛跑的那個非同步作業的結果儲存下下，換人：

// 實際上handler h = someOS.asyncReadFile("/root") //很快返回一個handlerwhile (!h.finishedAsyncReadFile()): //很快返回Y/N  go.scheduler.儲存現狀()  go.scheduler.跑夠了_換人() // 相當於return，不過下次會從這裡的下一句開始執行string s = h.getResultFromAsyncRead()

然後scheduler就換下一個goroutine跑了。等下次再跑回剛才那個goroutine的時候，他就看看，說那個asyncReadFile到底執行完沒有啊，如果沒有，就再換個人吧。如果執行完了，那就把結果拿出來，該幹嘛幹嘛。所以你看似寫了個同步的操作，已經被go替換成非同步作業了。

還有另外一種情況是，某個goroutine執行了某個不能非同步呼叫的會blocking的系統調用，這個時候goroutine就沒法玩那種非同步呼叫的把戲了。他會把你挪到一個真正的線程裡讓你在那個縣城裡等著，他接茬去跑別的goroutine。比如A這麼定義

def A:  print("do something")  go.os.InvokeSomeReallyHeavyAndBlockingSystemCall()  print("do something 2")

go會幫你轉成

def 真實的A:  print("do something")  Thread t = new Thread( () => {    SomeReallyHeavyAndBlockingSystemCall();  })  t.start()  while !t.finished():    go.scheduler.儲存現狀    go.scheduler.跑夠了_換人  print("finished")

所以真實的A還是不會blocking，還是可以跟別的小夥伴(goroutine)愉快地玩耍（輪流往複的被執行），但他其實已經佔了一個真是的系統線程了。

當然會有一種情況就是A完全沒有調用任何可能的“非同步並發”的操作，也沒有調用任何的同步的系統調用，而是一個勁的用CPU做運算（比如用個死迴圈調用a++）。在早期的go裡，這個A就把整個程式block住了。後面新版本的go好像會有一些處理辦法，比如如果你A裡面call了任意一個別的函數的話，就有一定幾率被踢下去換人。好像也可以自己主動說我要換人的，可以去查查新的go的spec