Golang的CSP很酷？其实.NET也可以轻松完成
CSP（Communicating sequential processes）
這東西我一開始以為很簡單，后面差了資料發現它獨樹一幟，自己是一門語言，也是一套理論。這邊我不深入的對它做過多的見解，我怕耽誤大家=_=，大家可以看看wiki。
wiki：https://en.wikipedia.org/wiki/Communicating_sequential_processes
我們從Go的角度對它進行一些分析，摘抄一段概要：
“用于描述兩個獨立的并發實體通過共享的通訊 channel(管道)進行通信的并發模型。 CSP中channel是第一類對象，它不關注發送消息的實體，而關注與發送消息時使用的channel。”
好了，單獨寫出 CSP 是為了讓大家了解這是一套獨立于語言的東西，大家有興趣可以查看wiki和搜索一些其它資料。
在Go中的CSP
Channel（通道）
Goroutine（不知道怎么翻譯，大家可以理解成一個“工作者”，不是工作者線程。本質是實現了協程。）
協程（提升并發的利器）
大家都很明白線程能做什么，但協程是個什么東西？比起線程又如何呢？
線程
我們重新思考一些東西。
CPU：核心、超線程
OS：線程
編程語言：線程池
這邊不做細講，只是大概點到一下。
我們所做的任何計算都要經由CPU計算，而CPU的核數直接決定了我們能給CPU執行幾件事情。
我們現在所常用的OS內部都有一個輪詢，用時間片的形式來分配任何輪流使用CPU執行計算，線程就是這些任務的載體。
這塊的概念非常龐大（還有牽扯到，什么是并發，什么事并行），本文的重點不是這些，大家有興趣后面可以單獨開一篇文章來解釋這塊的內容。
回歸本文，現在我們知道線程是操作系統級別用來共享CPU的一種技術實現，多線程編程早在各大語言遍地開花，被用的惟妙惟肖，百花齊放。
那么為什么需要協程呢？
線程的開銷
這塊又是一個大知識點，這邊也不多做介紹。
大家只要明白，線程并不是廉價的，一個線程的創立有至少兩點的開銷
內存
調度器壓力（線程上下文切換等）
線程是可以持有邏輯數據的（比如，HttpContext.Current，等對象）所以必定是占用內存的（至于占用了多少內存不同的語言和OS不一樣）
如果一個CPU是4核的，同時就只能處理4件任務，一個OS的線程越多他們輪訓一整圈所耗的時間就更長。而每次調度線程時都需要復制當前線程上下文的狀態，再去讀取準備調度線程上下文的狀態。
這邊可以看到最后一點，有時候多線程反而會比單線程更加的慢，所以多線程提升性能本質上其實是假的。多線程并不會提升程序性能。
我知道這邊肯定有人會心存疑問，絕大數的人都說用多線程來提升性能，為什么這邊說多線程會比單線程慢？
我們這邊想一下：PHP 和 NodeJS，PHP默認不支持多線程，NodeJS采用單線程事件輪詢，他們的效率比擁有多線程的語言低嗎？并不會。
多線程之所以快是因為作弊，別人一個人干的事情你叫兩個人去干當然會比單線程快。這也有非常大的限制，多線程所執行的東西盡可能避免共享，不然你的效率還是可能不如單線程。
這邊說的有點跑題，這塊的內容實在太大，大家只要知道，線程即使不昂貴也絕不廉價。
針對這個問題，各大語言都推出了一個叫做線程池的技術，我申請一批線程，持有他，等到有任務的時候直接使用，這樣我就不會頻繁的創建和銷毀線程了。這樣大大提升了效率。
在.NET中，很早就提倡任何需要線程的時刻都使用?ThreadPool。
ps:現在覺大多數（我還沒見過）的語言（runtime）中，線程與操作系統的線程是一一對應的。
回歸協程
協程與線程是一對多的關系，有多個協程會對應到一根線程上。跟線程和CPU是一樣的關系。
線程是為了共享CPU，而協程是為了共享線程。
協程是應用層面的自有“線程”實現。也就是說在不改變OS的線程邏輯下，自己構建了一套 “線程”系統。
為什么不直接改動OS的線程，讓其更輕？我個人覺得 1是歷史兼容性問題，2是必要性問題，線程是一個很好的抽象邏輯。實現協程完全可以通過線程來完成。
協程的目的
我們來思考一個場景
抓取百度、google、bing的html。
多線程的做法是
啟動三個線程，分別對百度、google、bing發起HTTP GET請求。這時候使用了三個線程。
協程的做法是（極端）
啟動一個線程對百度發起HTTP GET請求，將任務放入隊列，在對google發起HTTP GET請求，將任務放入隊列，在對bingHTTP GET請求將任務放入隊列。
這時候只需要使用一個線程（極端情況下，其實大多數實現來說至少需要兩個線程，因為需要有一個后臺線程去監聽任務隊列，當任務完成后再分配一個可用線程去處理下面的邏輯）
為什么說極端情況下？因為協程有時候也可能會與線程一一對應，比如你的CPU有8個核心，同時跑4個協程也有可能會分配4根線程單獨去處理這4個任務，這主要取決于調度算法。
總結：協程是為了提升線程利用率，減少線程的無用功（大多數是IO堵塞），協程也更適合IO密集型的場景。
回到目錄
C#中的協程
可以看到，3個任務是異步執行的，但都由線程4來處理，也就是說三個異步任務只用了一根線程。
C#中的CSP
講了這么大篇幅的協程，終于回歸了今天的主題。
其實單單實現CSP來說根本不用理清線程和協程。但今天主要對比的是Go中的CSP，所以如果沒有協程基本是沒有意義的。
C#如何對應，CSP中最重要的Channel呢？
答案就是：BlockingCollection<T>
我們來看一個例子
抓取一批網站并輸出網站的title
發起 HTTP GET 請求 和分析Title的代碼邏輯如下：
主程序的代碼如下：
執行邏輯
啟用一個生產者協程來根據url生產對應的html、同時使用主線程消費隊列內的內容（異步）
每個url單獨起一個協程來發起HTTP GET請求
生產者協程等待所有url的html全部加載完成
標志隊列完成
主線程退出
執行結果如下：
Go協程與.NET協程的區別？
去除實現上的一些邏輯，本質上沒太多區別。
但Go有一個天生優勢就是它是新時代的語言，拋棄了線程。也就是說Go層面沒有線程的東西，它只有協程。
但.NET中線程已經擁有了好多年，大量的類庫、驅動使用線程來完成。
所以你在上一層就算使用了協程，執行到底部不一定只有一根線程來完成，底部可以自己創建線程來運行邏輯，今天篇幅關系不做過多說明。后面我們在介紹這塊的內容。
寫在最后
最后總結一個要點，多線程、協程并不能提升性能，它們所達到的目的只是提高CPU利用率。
今天本來想詳細寫BlockingCollection<T>的使用說明，但協程等概念占了大量的篇幅，后面我們再來詳細介紹.NET中的異步編程。
.NET技術棧QQ群：384413261（點擊加入?.NET Group）
相關文章：
解析Visual C# 7.2中的private protected訪問修飾符
C# - Span 全面介紹：探索 .NET 新增的重要組成部分
C#中的原子操作Interlocked，你真的了解嗎？
C# 7.1、7.2特性追蹤
SIMD via C#
C#中的兩把雙刃劍：抽象類和接口
原文：https://www.cnblogs.com/ants/p/8601947.html
.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com
總結
以上是生活随笔為你收集整理的Golang的CSP很酷？其实.NET也可以轻松完成的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 大规模开发团队如何实现DevOps转型？
- 下一篇： asp.net ajax控件工具集 Au