關於併發和並行的區別，這兒不做討論，另外併發這個詞是否準確，我也不想深究，我只想描述一個都有機會被cpu臨幸的現象，不管是如何實現的。
os和語言演化的過程就是要榨乾計算機性能的過程。
很久以前，計算機處理任務是串行的，一件事情處理完才能處理另外一件事，那時候好單純。
看起來還不錯。
後來，發現計算機裏的各個部件的速度並不一致，甚至差了好幾個數量級，這中間尤其cpu最快，io最慢，那麼如何充分利用閒置的cpu呢？
那就讓多個程序一塊兒運行，os負責調度哪個程序，在哪個時間段來運行。
看起來還不錯啊。
互聯網的興起讓web開發變得異常火熱，每個web應用可以服務於成千十萬人，每個人接入時就會啓動一個process，同時訪問的人數少些還能承受，
可一旦太多，os也承受不了，畢竟啓動一個process花費時間也蠻多的。
這時候，就有了thread，比process輕多了，每接待一個訪問，起一個thread就好了。
看起來還不錯。
可是後來發現thread還是太重，有同時啓動thread數量的限制，並且創建和切換thread也是件費時的處理。
這時候發現，其實web上數據處理並不佔主流，大多數時間的等待都在io等待上，也就是說創建了多個thread，cpu也時常處於閒置狀態。
這時候，事件驅動模式就來了，比如node.js，用一個線程去接待用戶接入，使用異步io處理的方式，在數據準備晚之前，不停輪訓，
這樣雖然總的處理時間雖然不會變少，但是至少每個人都有機會接入，並且那些雖然在時間上來看晚一些訪問的人，也有可能提前返回結果。
看起來還不錯。
但是，但是（爲什麼還有但是呢）web雖然數據處理不佔主流，並不代表沒有，一點主線程進行大量計算時，輪詢也就停止了，除了計算一切都停止了。
當然，你可以啓多個線程來輪詢，也可以把計算放到另外一個線程上，但這些都要自己實現，語言是做不了的。
如果在cpu做運算時能把運行片段讓出就好了，協程好像可以，協程很輕量，隨隨便便就能啓動成千上萬，並且切換的cost也很小。
但是協程得需要用戶自己來調度，os是管不了的，這哪行，誰能很好的決定要在數據處理的哪個邏輯上讓出cpu呢。
咋辦？這時候便有了golang，簡直神器啊，隨隨便便啓動多個goruntine，可以自己調度，vm還可以幫着調度，佔用時間比較多的gorunting讓出cpu。
一舉消滅了線程重，事件驅動的單線程阻塞問題，並且不同於其它語言的協程，goruntine是可以有vm調度。
至少現在可以說是完美。