最近在研究網絡服務框架方面的東西,發現了1個奇異的東西-協程。
1句話說明甚么是線程:協程是1種用戶態的輕量級線程。
1句話其實不能完全概括協程的全部,但是最少能讓我們對協程這個概念有1個基本的印象。
從硬件發展來看,從最初的單核單CPU,到單核多CPU,多核多CPU,似乎已到了極限了,但是單核CPU性能卻還在不斷提升。server端也在不斷的發展變化。如果將程序分為IO密集型利用和CPU密集型利用,2者的server的發展以下:
IO密集型利用: 多進程->多線程->事件驅動->協程
CPU密集型利用:多進程-->多線程
如果說多進程對多CPU,多線程對應多核CPU,那末事件驅動和協程則是在充分發掘不斷提高性能的單核CPU的潛力。
以下的討論如無特別說明,不斟酌cpu密集型利用。
不管是線程還是進程,使用的都是同步進制,當產生阻塞時,性能會大幅度下降,沒法充分利用CPU潛力,浪費硬件投資,更重要造成軟件模塊的鐵板化,緊耦合,沒法切割,不利于往后擴大和變化。不論是進程還是線程,每次阻塞、切換都需要墮入系統調用(system call),先讓CPU跑操作系統的調度程序,然后再由調度程序決定該跑哪個進程(線程)。多個線程之間在1些訪問互斥的代碼時還需要加上鎖,這也是致使多線程編程難的緣由之1。
現下流行的異步server都是基于事件驅動的(如nginx)。事件驅動簡化了編程模型,很好地解決了多線程難于編程,難于調試的問題。異步事件驅動模型中,把會致使阻塞的操作轉化為1個異步操作,主線程負責發起這個異步操作,并處理這個異步操作的結果。由于所有阻塞的操作都轉化為異步操作,理論上主線程的大部份時間都是在處理實際的計算任務,少了多線程的調度時間,所以這類模型的性能通常會比較好。
總的說來,當單核cpu性能提升,cpu不在成為性能瓶頸時,采取異步server能夠簡化編程模型,也能提高IO密集型利用的性能。
之前說道,協程是1種用戶級的輕量級線程。協程具有自己的寄存器上下文和棧。協程調度切換時,將寄存器上下文和棧保存到其他地方,在切回來的時候,恢復先前保存的寄存器上下文和棧。因此:
協程能保存上1次調用時的狀態(即所有局部狀態的1個特定組合),每次進程重入時,就相當于進入上1次調用的狀態,換種說法:進入上1次離開時所處邏輯流的位置。
在并發編程中,協程與線程類似,每一個協程表示1個履行單元,有自己的本地數據,與其它協程同享全局數據和其它資源。目前主流語言基本上都選擇了多線程作為并發設施,與線程相干的概念是搶占式多任務(Preemptive multitasking),而與協程相干的是協作式多任務。
不論是進程還是線程,每次阻塞、切換都需要墮入系統調用(system call),先讓CPU跑操作系統的調度程序,然后再由調度程序決定該跑哪個進程(線程)。
而且由于搶占式調度履行順序沒法肯定的特點,使用線程時需要非常謹慎地處理同步問題,而協程完全不存在這個問題(事件驅動和異步程序也有一樣的優點)。
我們在自己在進程里面完成邏輯流調度,碰著io我就用非阻塞式的。那末我們便可以利用到異步優勢,又可以免反復系統調用,還有進程切換釀成的開消,分分鐘給你上幾千個邏輯流不費力。這就是協程。
以nginx為代表的事件驅動的異步server正在橫掃天下,那末事件驅動模型會是server端模型的終點嗎?
我們可以深入了解下,事件驅動編程的模型。
事件驅動編程的架構是預先設計1個事件循環,這個事件循環程序不斷地檢查目前要處理的信息,根據要處理的信息運行1個觸發函數。其中這個外部信息可能來自1個目錄夾中的文件,可能來自鍵盤或鼠標的動作,或是1個時間事件。這個觸發函數,可以是系統默許的也能夠是用戶注冊的回調函數。
事件驅動程序設計側重于彈性和異步化上面。許多GUI框架(如windows的MFC,Android的GUI框架),Zookeeper的Watcher等都使用了事件驅動機制。未來還會有其他的基于事件驅動的作品出現。
基于事件驅動的編程是單線程思惟,其特點是異步+回調。
協程也是單線程,但是它能讓原來要使用異步+回調方式寫的非人類代碼,可以用看似同步的方式寫出來。它是實現推拉互動的所謂非搶占式協作的關鍵。
協程的好處:
缺點: