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") //很快返回一個handler
while (!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