Gevent官網(wǎng)文檔地址：http://www.gevent.org/contents.html

基本概念

我們通常所說的協(xié)程Coroutine其實(shí)是corporateroutine的縮寫，直接翻譯為協(xié)同的例程，一般我們都簡(jiǎn)稱為協(xié)程。

在linux系統(tǒng)中，線程就是輕量級(jí)的進(jìn)程，而我們通常也把協(xié)程稱為輕量級(jí)的線程即微線程。

進(jìn)程和協(xié)程

下面對(duì)比一下進(jìn)程和協(xié)程的相同點(diǎn)和不同點(diǎn)：

相同點(diǎn)：

我們都可以把他們看做是一種執(zhí)行流，執(zhí)行流可以掛起，并且后面可以在你掛起的地方恢復(fù)執(zhí)行，這實(shí)際上都可以看做是continuation,關(guān)于這個(gè)我們可以通過在linux上運(yùn)行一個(gè)hello程序來理解：

shell進(jìn)程和hello進(jìn)程：

開始，shell進(jìn)程在運(yùn)行，等待命令行的輸入

執(zhí)行hello程序，shell通過系統(tǒng)調(diào)用來執(zhí)行我們的請(qǐng)求，這個(gè)時(shí)候系統(tǒng)調(diào)用會(huì)講控制權(quán)傳遞給操作系統(tǒng)。操作系統(tǒng)保存shell進(jìn)程的上下文，創(chuàng)建一個(gè)hello進(jìn)程以及其上下文并將控制權(quán)給新的hello進(jìn)程。

hello進(jìn)程終止后，操作系統(tǒng)恢復(fù)shell進(jìn)程的上下文，并將控制權(quán)傳回給shell進(jìn)程

shell進(jìn)程繼續(xù)等待下個(gè)命令的輸入

當(dāng)我們掛起一個(gè)執(zhí)行流的時(shí)，我們要保存的東西：

棧，其實(shí)在你切換前你的局部變量，以及要函數(shù)的調(diào)用都需要保存，否則都無法恢復(fù)

寄存器狀態(tài),這個(gè)其實(shí)用于當(dāng)你的執(zhí)行流恢復(fù)后要做什么

而寄存器和棧的結(jié)合就可以理解為上下文，上下文切換的理解：

CPU看上去像是在并發(fā)的執(zhí)行多個(gè)進(jìn)程，這是通過處理器在進(jìn)程之間切換來實(shí)現(xiàn)的，操作系統(tǒng)實(shí)現(xiàn)這種交錯(cuò)執(zhí)行的機(jī)制稱為上下文切換

操作系統(tǒng)保持跟蹤進(jìn)程運(yùn)行所需的所有狀態(tài)信息。這種狀態(tài)，就是上下文。

在任何一個(gè)時(shí)刻，操作系統(tǒng)都只能執(zhí)行一個(gè)進(jìn)程代碼，當(dāng)操作系統(tǒng)決定把控制權(quán)從當(dāng)前進(jìn)程轉(zhuǎn)移到某個(gè)新進(jìn)程時(shí)，就會(huì)進(jìn)行上下文切換，即保存當(dāng)前進(jìn)程的上下文，恢復(fù)新進(jìn)程的上下文，然后將控制權(quán)傳遞到新進(jìn)程，新進(jìn)程就會(huì)從它上次停止的地方開始。

不同點(diǎn)：

執(zhí)行流的調(diào)度者不同，進(jìn)程是內(nèi)核調(diào)度，而協(xié)程是在用戶態(tài)調(diào)度，也就是說進(jìn)程的上下文是在內(nèi)核態(tài)保存恢復(fù)的，而協(xié)程是在用戶態(tài)保存恢復(fù)的，很顯然用戶態(tài)的代價(jià)更低

進(jìn)程會(huì)被強(qiáng)占，而協(xié)程不會(huì)，也就是說協(xié)程如果不主動(dòng)讓出CPU，那么其他的協(xié)程，就沒有執(zhí)行的機(jī)會(huì)。

對(duì)內(nèi)存的占用不同，實(shí)際上協(xié)程可以只需要4K的棧就足夠了，而進(jìn)程占用的內(nèi)存要大的多

從操作系統(tǒng)的角度講，多協(xié)程的程序是單進(jìn)程，單協(xié)程

線程和協(xié)程

既然我們上面也說了，協(xié)程也被稱為微線程，下面對(duì)比一下協(xié)程和線程：

線程之間需要上下文切換成本相對(duì)協(xié)程來說是比較高的，尤其在開啟線程較多時(shí)，但協(xié)程的切換成本非常低。

同樣的線程的切換更多的是靠操作系統(tǒng)來控制，而協(xié)程的執(zhí)行由我們自己控制

我們通過下面的圖更容易理解：

從上圖可以看出，協(xié)程只是在單一的線程里不同的協(xié)程之間切換，其實(shí)和線程很像，線程是在一個(gè)進(jìn)程下，不同的線程之間做切換，這也可能是協(xié)程稱為微線程的原因吧

繼續(xù)分析協(xié)程：

Gevent

Gevent是一種基于協(xié)程的Python網(wǎng)絡(luò)庫，它用到Greenlet提供的，封裝了libevent事件循環(huán)的高層同步API。它讓開發(fā)者在不改變編程習(xí)慣的同時(shí)，用同步的方式寫異步I/O的代碼。

使用Gevent的性能確實(shí)要比用傳統(tǒng)的線程高，甚至高很多。但這里不得不說它的一個(gè)坑：

Monkey-patching，我們都叫猴子補(bǔ)丁，因?yàn)槿绻褂昧诉@個(gè)補(bǔ)丁，Gevent直接修改標(biāo)準(zhǔn)庫里面大部分的阻塞式系統(tǒng)調(diào)用，包括socket、ssl、threading和select等模塊，而變?yōu)閰f(xié)作式運(yùn)行。但是我們無法保證你在復(fù)雜的生產(chǎn)環(huán)境中有哪些地方使用這些標(biāo)準(zhǔn)庫會(huì)由于打了補(bǔ)丁而出現(xiàn)奇怪的問題

第三方庫支持。得確保項(xiàng)目中用到其他用到的網(wǎng)絡(luò)庫也必須使用純Python或者明確說明支持Gevent

既然Gevent用的是Greenlet，我們通過下圖來理解greenlet:

每個(gè)協(xié)程都有一個(gè)parent,最頂層的協(xié)程就是man thread或者是當(dāng)前的線程，每個(gè)協(xié)程遇到IO的時(shí)候就把控制權(quán)交給最頂層的協(xié)程，它會(huì)看那個(gè)協(xié)程的IO event已經(jīng)完成，就將控制權(quán)給它。

下面是greenlet一個(gè)例子

from greenlet import greenlet

def test1(x,y):
  z = gr2.switch(x+y)
  print(z)

def test2(u):
  print(u)
  gr1.switch(42)

gr1 = greenlet(test1)
gr2 = greenlet(test2)

gr1.switch("hello",'world')

greenlet(run=None, parent=None): 創(chuàng)建一個(gè)greenlet實(shí)例.
gr.parent:每一個(gè)協(xié)程都有一個(gè)父協(xié)程,當(dāng)前協(xié)程結(jié)束后會(huì)回到父協(xié)程中執(zhí)行,該 屬性默認(rèn)是創(chuàng)建該協(xié)程的協(xié)程.
gr.run: 該屬性是協(xié)程實(shí)際運(yùn)行的代碼. run方法結(jié)束了,那么該協(xié)程也就結(jié)束了.
gr.switch(*args, **kwargs): 切換到gr協(xié)程.
gr.throw(): 切換到gr協(xié)程,接著拋出一個(gè)異常.

下面是gevent的一個(gè)例子：

import gevent
def func1():
  print("start func1")
  gevent.sleep(1)
  print("end func1")
def func2():
  print("start func2")
  gevent.sleep(1)
  print("end func2")

gevent.joinall(
  [
    gevent.spawn(func1),
    gevent.spawn(func2)
  ]
)

關(guān)于gevent中隊(duì)列的使用

gevent中也有自己的隊(duì)列，但是有一個(gè)場(chǎng)景我用的過程中發(fā)現(xiàn)一個(gè)問題，就是如果我在協(xié)程中通過這個(gè)q來傳遞數(shù)據(jù)，如果對(duì)了是空的時(shí)候，從隊(duì)列獲取數(shù)據(jù)的那個(gè)協(xié)程就會(huì)被切換到另外一個(gè)協(xié)程中，這個(gè)協(xié)程用于往隊(duì)列里put放入數(shù)據(jù),問題就出在，gevent不認(rèn)為這個(gè)放入數(shù)據(jù)為IO操作，并不會(huì)切換到上一個(gè)協(xié)程中，會(huì)把這個(gè)協(xié)程的任務(wù)完成后在切換到另外一個(gè)協(xié)程。我原本想要實(shí)現(xiàn)的效果是往對(duì)了放入數(shù)據(jù)后就會(huì)切換到get的那個(gè)協(xié)程。（或許我這里理解有問題）下面是測(cè)試代碼：

import gevent
from gevent.queue import Queue
def func():
  for i in range(10):

    print("int the func")
    q.put("test")
def func2():
  for i in range(10):
    print("int the func2")
    res = q.get()
    print("--->",res)
q = Queue()
gevent.joinall(
  [
    gevent.spawn(func2),
    gevent.spawn(func),
  ]
)

這段代碼的運(yùn)行效果為：

如果我在fun函數(shù)的q.put("test")后面添加gevent.sleep(0),就會(huì)是如下效果：

原本我預(yù)測(cè)的在不修改代碼的情況下就應(yīng)該是第二個(gè)圖的結(jié)果，但是實(shí)際卻是第一個(gè)圖的結(jié)果（這個(gè)問題可能是我自己沒研究明白，后面繼續(xù)研究）

關(guān)于Gevent的問題

就像我上面說的gevent和第三方庫配合使用會(huì)有一些問題，可以總結(jié)為：
python協(xié)程的庫可以直接monkey path
C寫成的庫可以采用豆瓣開源的greenify來打patch(這個(gè)功能自己準(zhǔn)備后面做測(cè)試)

不過總的來說gevent目前為止還是有很多缺陷，并且不是官網(wǎng)標(biāo)準(zhǔn)庫，而在python3中有一個(gè)官網(wǎng)正在做并且在3.6中已經(jīng)穩(wěn)定的庫asyncio,這也是一個(gè)非常具有野心的庫，非常建議學(xué)習(xí)，我也準(zhǔn)備后面深入了解

總結(jié)

以上就是本文關(guān)于Python并發(fā)編程協(xié)程(Coroutine)之Gevent詳解的全部?jī)?nèi)容，希望對(duì)大家有所幫助。感興趣的朋友可以繼續(xù)參閱本站其他相關(guān)專題，如有不足之處，歡迎留言指出。感謝朋友們對(duì)本站的支持！

最新評(píng)論