① python多進程multiprocessing模塊介紹
multiprocessing 是一個支持使用與 threading 模塊類似的 API 來產生進程的包。 multiprocessing 包同時提供了本地和遠程並發操作，通過使用子進程而非線程有效地繞過了 全局解釋器鎖。 因此，multiprocessing 模塊允許程序員充分利用給定機器上的多個處理器。 它在 Unix 和 Windows 上均可運行。
1、multiprocessing.Process(group=None, target=None, name=None, args=(), kwargs={}, *, daemon=None)
2、相關方法
輸出結果如下：
Pool提供了一種快捷的方法，賦予函數並行化處理一系列輸入值的能力，可以將輸入數據分配給不同進程處理（數據並行）。下面的例子演示了在模塊中定義此類函數的常見做法，以便子進程可以成功導入該模塊。這個數據並行的基本例子使用了 Pool 。
將在標准輸出中列印
其中：
（1）p.apply(func [, args [, kwargs]]):在一個池工作進程中執行func( args, kwargs),然後返回結果。需要強調的是：此操作並不會在所有池工作進程中並執行func函數。如果要通過不同參數並發地執行func函數，必須從不同線程調用p.apply()函數或者使用p.apply_async()
（2）p.apply_async(func [, args [, kwargs]]):在一個池工作進程中執行func( args,**kwargs),然後返回結果。此方法的結果是 AsyncResult類的實例，callback是可調用對象，接收輸入參數。當func的結果變為可用時，將理解傳遞給callback。callback禁止執行任何阻塞操作，否則將接收其他非同步操作中的結果。多進程並發！
（3）p.close():關閉進程池，防止進一步操作。如果所有操作持續掛起，它們將在工作進程終止前完成
（4）p.jion():等待所有工作進程退出。此方法只能在close（）或teminate()之後調用
② Python入門系列（十二）——GUI+多進程
話說，python做圖形界面並不明智，效率並不高。但在某些特殊需求下還是需要我們去使用，所以python擁有多個第三方庫用以實現GUI，本章我們使用python基本模塊tkinter進行學習，因為需求並不大，所以不做太多拓展。
繼續改寫上一章的IP查詢系統（= =，要玩爛了），首先略改下IpWhere.py以備調用~
然後使用tkinter模塊進行圖形界面的實現，調用預編譯的IpWhere模塊 ：
額，太丑了，但基本實現我們小小的需求，在以後的py學習中，我們再涉及其他的第三方模塊，此處就當是入門了解吧。
十分抱歉把這么重要的內容放在最後，要不是大佬指點，此次學習可能就要錯過多進程的問題了。
Unix系統提供了forx，python可藉助os模塊調用，從而實現多進程，然而windows系統並不具備，所以我們選擇python內置的multiprocessing多進程模塊進行學習。
首先我們藉助直接調用多進程來改寫下我們在多線程章節用到的例子！
顯然，這么寫實在太蠢了，如果我們的任務量巨大，這並不合適。所以我們引入了進程池的概念，使用進程池進行改寫：
在此，我們可以看到所有進程是並發執行的，同樣，我們在多線程章節就講過，主進程的結束意味著程序退出，所以我們需要藉助join()方法堵塞進程。
我們知道線程共享內存空間，而進程的內存是獨立的，同一個進程的線程之間可以直接交流，也就帶來了線程同步的苦惱，這個我們在多線程章節已經講過了；而兩個進程想通信，則必須通過一個中間代理來實現，即我們接下來的內容：進程間通信。
進程之間肯定是需要通信的，操作系統提供了很多機制來實現進程間的通信。Python的multiprocessing模塊包裝了底層的機制，提供了Queue、Pipes等多種方式來交換數據。我們接下來就以Queue的方式進行學習。
Queue.Queue是進程內非阻塞隊列，multiprocess.Queue是跨進程通信隊列，前者是各自私有，後者是各子進程共有。
還有一個在後者基礎上進行封裝的multiprocess.Manager.Queue()方法，如果要使用Pool創建進程，就需要使用multiprocessing.Manager()中的Queue()，而不是multiprocessing.Queue()，否則會得到一條如下的錯誤信息： RuntimeError: Queue objects should only be shared between processes through inheritance.
接下來我們就藉助進程池來進行多進程操作的改寫，感謝大佬一路輔導。
我們可以看到兩個子線程先執行，然後一個子線程單獨執行，此處有意而為之，讓大家更清晰的了解隊列的使用。期間有一處我們放棄使用jion()方法堵塞，而是自己寫了個循環堵塞，大家根據自己習慣來就好。
話說，真的沒人吐槽么？上面的例子從需求上來講，完全就不需要多線程好不好！emmmm，我們來點實力拓展，寫一個有智商的多線程腳本，順便結合上一節的web來一個綜合篇，隨便找個現實需求吧！
emmm，比如我們來到當當網買書，搜一下我們想要的書籍，發現！！太多了！！真J2亂！！看不過來！！不想翻頁！！直接告訴我哪個便宜、哪個牛逼好不好！！
簡單看下這個url：
http://search.dangdang.com/?key=滲透測試&ddsale=1&page_index=2
其中ddsale參數代表當當自營，page_index代表頁數，key代表搜索內容，我們本次的變數只有頁數。
所以我們構造請求的url為:
'http://search.dangdang.com/?key=滲透測試&ddsale=1&page_index='+str(page)
如果修改的內容不使用str字元串轉化，會收到如下報錯：
TypeError: can only concatenate str (not "int") to str
然後我們看一下頁面內容的分布情況，本次我們關心賣什麼書，賣多少錢？
對應的編寫我們的正則匹配規則，當然了，有更簡便的第三方庫可以幫我們處理，但為了更好的形成流程性認識，我們這里依然使用正則。
我們對應我們需要的書籍名稱和當前價格匹配如下：
<a title=" (.*?)" ddclick=
<span class="search_now_price">¥(.*?)</span>
那麼，思路理清了，我們就開始使用多線程來寫我們的小系統~
然後我們去查看一下我們的結果文件~
現在這個小系統具備的功能就是根據用戶需要選擇要檢索的書籍，然後整理下名稱和價格，開了10個線程，如果小夥伴pc給力的話可以繼續加。簡單的異常處理機制和界面交互，基本滿足日常所需。
③ python 多進程
基於官方文檔：
https://docs.python.org/zh-cn/3/library/multiprocessing.html
日樂購，剛才看到的一個博客，寫的都不太對，還是基於官方的比較穩妥
我就是喜歡抄官方的，哈哈
通常我們使用Process實例化一個進程，並調用 他的 start() 方法啟動它。
這種方法和 Thread 是一樣的。
上圖中，我寫了 p.join() 所以主進程是 等待 子進程執行完後，才執行 print("運行結束")
否則就是反過來了（這個不一定，看你的語句了，順序其實是隨機的）例如：
主進加個 sleep
所以不加join() ,其實子進程和主進程是各干各的，誰也不等誰。都執行完後，文件運行就結束了
上面我們用了 os.getpid() 和 os.getppid() 獲取 當前進程，和父進程的id
下面就講一下，這兩個函數的用法：
os.getpid()
返回當前進程的id
os.getppid()
返回父進程的id。 父進程退出後，unix 返回初始化進程（1）中的一個
windows返回相同的id (可能被其他進程使用了)
這也就解釋了，為啥我上面 的程序運行多次， 第一次列印的parentid 都是 14212 了。
而子進程的父級 process id 是調用他的那個進程的 id ： 1940
視頻筆記：
多進程：使用大致方法：
參考： 進程通信（pipe和queue）
pool.map （函數可以有return 也可以共享內存或queue） 結果直接是個列表
poll.apply_async() （同map,只不過是一個進程，返回結果用 xx.get() 獲得）
報錯：
參考 ： https://blog.csdn.net/xiemanR/article/details/71700531
把 pool = Pool() 放到 if name == " main ": 下面初始化搞定。
結果：
這個肯定有解釋的
測試多進程計算效果：
進程池運行：
結果：
普通計算：
我們同樣傳入 1 2 10 三個參數測試：
其實對比下來開始快了一半的；
我們把循環里的數字去掉一個 0；
單進程：
多進程：
兩次測試 單進程/進程池 分別為 0.669 和 0.772 幾乎成正比的。
問題 二：
視圖：
post 視圖裡面
Music 類：
直接報錯：
寫在 類裡面也 在函數里用 self.pool 調用也不行，也是相同的錯誤。
最後 把 pool = Pool 直接寫在 search 函數裡面，奇跡出現了：
前台也能顯示搜索的音樂結果了
總結一點，進程這個東西，最好 寫在 直接運行的函數裡面，而不是 一個函數跳來跳去。因為最後可能 是在子進程的子進程運行的，這是不許的，會報錯。
還有一點，多進程運行的函數對象，不能是 lambda 函數。也許lambda 虛擬，在內存？？
使用 pool.map 子進程 函數報錯，導致整個 pool 掛了:
參考： https://blog.csdn.net/hedongho/article/details/79139606
主要你要，對函數內部捕獲錯誤，而不能讓異常拋出就可以了。
關於map 傳多個函數參數
我一開始，就是正常思維，多個參數，搞個元祖，讓參數一一對應不就行了：
報錯：
參考：
https://blog.csdn.net/qq_15969343/article/details/84672527
普通的 process 當讓可以穿多個參數，map 卻不知道咋傳的。
apply_async 和map 一樣，不知道咋傳的。
最簡單的方法：
使用 starmap 而不是 map
結果：
子進程結束
1.8399453163146973
成功拿到結果了
關於map 和 starmap 不同的地方看源碼：
關於apply_async() ,我沒找到多參數的方法，大不了用 一個迭代的 starmap 實現。哈哈
關於 上面源碼裡面有 itertools.starmap
itertools 用法參考：
https://docs.python.org/zh-cn/3/library/itertools.html#itertool-functions
有個問題，多進程最好不要使用全部的 cpu , 因為這樣可能影響其他任務，所以 在進程池 添加 process 參數 指定，cpu 個數：
上面就是預留了 一個cpu 干其他事的
後面直接使用 Queue 遇到這個問題：
解決：
Manager().Queue() 代替 Queue()
因為 queue.get() 是堵塞型的，所以可以提前判斷是不是 空的，以免堵塞進程。比如下面這樣：
使用 queue.empty() 空為True
④ Python多進程運行——Multiprocessing基礎教程2
上篇文章簡單介紹了multiprocessing模塊，本文將要介紹進程之間的數據共享和信息傳遞的概念。
在多進程處理中，所有新創建的進程都會有這兩個特點：獨立運行，有自己的內存空間。
我們來舉個例子展示一下：
這個程序的輸出結果是：
在上面的程序中我們嘗試在兩個地方列印全局列表result的內容：
我們再用一張圖來幫助理解記憶不同進程間的數據關系：
如果程序需要在不同的進程之間共享一些數據的話，該怎麼做呢？不用擔心，multiprocessing模塊提供了Array對象和Value對象，用來在進程之間共享數據。
所謂Array對象和Value對象分別是指從共享內存中分配的ctypes數組和對象。我們直接來看一個例子，展示如何用Array對象和Value對象在進程之間共享數據：
程序輸出的結果如下：
成功了！主程序和p1進程輸出了同樣的結果，說明程序中確實完成了不同進程間的數據共享。那麼我們來詳細看一下上面的程序做了什麼：
在主程序中我們首先創建了一個Array對象：
向這個對象輸入的第一個參數是數據類型：i表示整數，d代表浮點數。第二個參數是數組的大小，在這個例子中我們創建了包含4個元素的數組。
類似的，我們創建了一個Value對象：
我們只對Value對象輸入了一個參數，那就是數據類型，與上述的方法一致。當然，我們還可以對其指定一個初始值（比如10），就像這樣：
隨後，我們在創建進程對象時，將剛創建好的兩個對象：result和square_sum作為參數輸入給進程：
在函數中result元素通過索引進行數組賦值，square_sum通過 value 屬性進行賦值。
注意：為了完整列印result數組的結果，需要使用 result[:] 進行列印，而square_sum也需要使用 value 屬性進行列印：
每當python程序啟動時，同時也會啟動一個伺服器進程。隨後，只要我們需要生成一個新進程，父進程就會連接到伺服器並請求它派生一個新進程。這個伺服器進程可以保存Python對象，並允許其他進程使用代理來操作它們。
multiprocessing模塊提供了能夠控制伺服器進程的Manager類。所以，Manager類也提供了一種創建可以在不同流程之間共享的數據的方法。
伺服器進程管理器比使用共享內存對象更靈活，因為它們可以支持任意對象類型，如列表、字典、隊列、值、數組等。此外，單個管理器可以由網路上不同計算機上的進程共享。
但是，伺服器進程管理器的速度比使用共享內存要慢。
讓我們來看一個例子：
這個程序的輸出結果是：
我們來理解一下這個程序做了什麼：首先我們創建了一個manager對象
在with語句下的所有行，都是在manager對象的范圍內的。接下來我們使用這個manager對象創建了列表（類似的，我們還可以用 manager.dict() 創建字典）。
最後我們創建了進程p1（用於在records列表中插入一條新的record）和p2（將records列印出來），並將records作為參數進行傳遞。
伺服器進程的概念再次用下圖總結一下：
為了能使多個流程能夠正常工作，常常需要在它們之間進行一些通信，以便能夠劃分工作並匯總最後的結果。multiprocessing模塊支持進程之間的兩種通信通道：Queue和Pipe。
使用隊列來回處理多進程之間的通信是一種比較簡單的方法。任何Python對象都可以使用隊列進行傳遞。我們來看一個例子：
上面這個程序的輸出結果是：
我們來看一下上面這個程序到底做了什麼。首先我們創建了一個Queue對象：
然後，將這個空的Queue對象輸入square_list函數。該函數會將列表中的數平方，再使用 put() 方法放入隊列中：
隨後使用 get() 方法，將q列印出來，直至q重新稱為一個空的Queue對象：
我們還是用一張圖來幫助理解記憶：
一個Pipe對象只能有兩個端點。因此，當進程只需要雙向通信時，它會比Queue對象更好用。
multiprocessing模塊提供了 Pipe() 函數，該函數返回由管道連接的一對連接對象。 Pipe() 返回的兩個連接對象分別表示管道的兩端。每個連接對象都有 send() 和 recv() 方法。
我們來看一個例子：
上面這個程序的輸出結果是：
我們還是來看一下這個程序到底做了什麼。首先創建了一個Pipe對象：
與上文說的一樣，該對象返回了一對管道兩端的兩個連接對象。然後使用 send() 方法和 recv() 方法進行信息的傳遞。就這么簡單。在上面的程序中，我們從一端向另一端發送一串消息。在另一端，我們收到消息，並在收到END消息時退出。
要注意的是，如果兩個進程(或線程)同時嘗試從管道的同一端讀取或寫入管道中的數據，則管道中的數據可能會損壞。不過不同的進程同時使用管道的兩端是沒有問題的。還要注意，Queue對象在進程之間進行了適當的同步，但代價是增加了計算復雜度。因此，Queue對象對於線程和進程是相對安全的。
最後我們還是用一張圖來示意：
Python的multiprocessing模塊還剩最後一篇文章：多進程的同步與池化
敬請期待啦！
⑤ python 多進程寫入同一個文件，經常報錯：找不到文件，該怎麼處理呢有沒有大神能貼個例子之類的參考下
importthreading,time
defwrite(file,lock):
lock.acquire()#鎖住
print("開始寫出")
file.write("寫出")
print("寫出完畢")
lock.release()#解鎖
returnTrue
lock=threading.Lock()#獲取一個鎖
file=open("1.txt")
foriinrange(100):
threading.Thread(target=write,args=(file,lock)).run()
⑥ Python實現多進程+進度條顯示
之前在寫繁體字轉簡體字的時候，由於數據量比較大，所以用了多進程來實現。其實我對多進程/多線程的認識只是了解概念，第一次看到實際的應用是在BDCI-OCR的項目中，作者用多進程進行圖像處理。毫無疑問，並行計算能顯著地減少運行時間。
那麼為什麼用多進程實現並行計算（多核任務），不用多線程呢？
引用鏈接
網上有很多實現多進程的示例，我只記錄自己用過的。
這里我用的是pool.apply_async()，是非同步非阻塞的方法，可以理解為：不用等待當前進程執行完畢，隨時根據系統調度來進行進程切換。當然，還有其他方法，網上有很多資料，我就不贅述了。
從運行結果中可以發現：因為cpu最大核心數是8，所以前8個任務的進程id都不一樣，任務9的進程id與任務2的相同，即任務2執行結束後再執行任務9，依此類推。
模擬的事件：共需處理10個任務，每個任務執行時間為5秒（5 * time.sleep(1)）
參考鏈接
發現：因為我的cpu是8核，所以10個任務的多進程耗時約為 2×單任務耗時 。
在查閱相關資料時發現，多進程在實際使用的時候有 單參數 和 多參數 之分，那麼多參數和單參數的優缺點分別是什麼呢？
⑦ python並發編程-進程池
在利用Python進行系統管理的時候，特別是同時操作多個文件目錄，或者遠程式控制制多台主機，並行操作可以節約大量的時間。多進程是實現並發的手段之一，需要注意的問題是：
例如當被操作對象數目不大時，可以直接利用multiprocessing中的Process動態成生多個進程，十幾個還好，但如果是上百個，上千個。。。手動的去限制進程數量卻又太過繁瑣，此時可以發揮進程池的功效。
我們就可以通過維護一個進程池來控制進程數目，比如httpd的進程模式，規定最小進程數和最大進程數..
ps： 對於遠程過程調用的高級應用程序而言，應該使用進程池，Pool可以提供指定數量的進程，供用戶調用，當有新的請求提交到pool中時，如果池還沒有滿，那麼就會創建一個新的進程用來執行該請求；但如果池中的進程數已經達到規定最大值，那麼該請求就會等待，直到池中有進程結束，就重用進程池中的進程。
創建進程池的類：如果指定numprocess為3，則進程池會從無到有創建三個進程，然後自始至終使用這三個進程去執行所有任務，不會開啟其他進程
參數介紹：
方法介紹：
主要方法：
其他方法（了解部分）
應用：
發現：並發開啟多個客戶端，服務端同一時間只有3個不同的pid，幹掉一個客戶端，另外一個客戶端才會進來，被3個進程之一處理
回調函數：
需要回調函數的場景：進程池中任何一個任務一旦處理完了，就立即告知主進程：我好了額，你可以處理我的結果了。主進程則調用一個函數去處理該結果，該函數即回調函數
我們可以把耗時間（阻塞）的任務放到進程池中，然後指定回調函數（主進程負責執行），這樣主進程在執行回調函數時就省去了I/O的過程，直接拿到的是任務的結果。
如果在主進程中等待進程池中所有任務都執行完畢後，再統一處理結果，則無需回調函數
⑧ 為什麼在Python里推薦使用多進程而不是多
最近在看Python的多線程，經常我們會聽到老手說：「Python下多線程是雞肋，推薦使用多進程！」，但是為什麼這么說呢？
要知其然，更要知其所以然。所以有了下面的深入研究：
首先強調背景：
1、GIL是什麼？
GIL的全稱是Global Interpreter Lock(全局解釋器鎖)，來源是python設計之初的考慮，為了數據安全所做的決定。
2、每個CPU在同一時間只能執行一個線程（在單核CPU下的多線程其實都只是並發，不是並行，並發和並行從宏觀上來講都是同時處理多路請求的概念。但並發和並行又有區別，並行是指兩個或者多個事件在同一時刻發生；而並發是指兩個或多個事件在同一時間間隔內發生。）
在Python多線程下，每個線程的執行方式：
1、獲取GIL
2、執行代碼直到sleep或者是python虛擬機將其掛起。
3、釋放GIL
可見，某個線程想要執行，必須先拿到GIL，我們可以把GIL看作是「通行證」，並且在一個python進程中，GIL只有一個。拿不到通行證的線程，就不允許進入CPU執行。
在Python2.x里，GIL的釋放邏輯是當前線程遇見IO操作或者ticks計數達到100（ticks可以看作是Python自身的一個計數器，專門做用於GIL，每次釋放後歸零，這個計數可以通過 sys.setcheckinterval 來調整），進行釋放。
而每次釋放GIL鎖，線程進行鎖競爭、切換線程，會消耗資源。並且由於GIL鎖存在，python里一個進程永遠只能同時執行一個線程(拿到GIL的線程才能執行)，這就是為什麼在多核CPU上，python的多線程效率並不高。
那麼是不是python的多線程就完全沒用了呢？
在這里我們進行分類討論：
1、CPU密集型代碼(各種循環處理、計數等等)，在這種情況下，由於計算工作多，ticks計數很快就會達到閾值，然後觸發GIL的釋放與再競爭（多個線程來回切換當然是需要消耗資源的），所以python下的多
⑨ python 多進程問題
兩個進程如果要同時運行，star函數挨著一起寫
⑩ python多進程為什麼一定要
前面講了為什麼Python里推薦用多進程而不是多線程，但是多進程也有其自己的限制：相比線程更加笨重、切換耗時更長，並且在python的多進程下，進程數量不推薦超過CPU核心數（一個進程只有一個GIL，所以一個進程只能跑滿一個CPU），因為一個進程佔用一個CPU時能充分利用機器的性能，但是進程多了就會出現頻繁的進程切換，反而得不償失。
不過特殊情況（特指IO密集型任務）下，多線程是比多進程好用的。
舉個例子：給你200W條url，需要你把每個url對應的頁面抓取保存起來，這種時候，單單使用多進程，效果肯定是很差的。為什麼呢？
例如每次請求的等待時間是2秒，那麼如下（忽略cpu計算時間）：
1、單進程+單線程：需要2秒*200W=400W秒==1111.11個小時==46.3天，這個速度明顯是不能接受的2、單進程+多線程：例如我們在這個進程中開了10個多線程，比1中能夠提升10倍速度，也就是大約4.63天能夠完成200W條抓取，請注意，這里的實際執行是：線程1遇見了阻塞，CPU切換到線程2去執行，遇見阻塞又切換到線程3等等，10個線程都阻塞後，這個進程就阻塞了，而直到某個線程阻塞完成後，這個進程才能繼續執行，所以速度上提升大約能到10倍（這里忽略了線程切換帶來的開銷，實際上的提升應該是不能達到10倍的），但是需要考慮的是線程的切換也是有開銷的，所以不能無限的啟動多線程（開200W個線程肯定是不靠譜的）3、多進程+多線程：這里就厲害了，一般來說也有很多人用這個方法，多進程下，每個進程都能佔一個cpu，而多線程從一定程度上繞過了阻塞的等待，所以比單進程下的多線程又更好使了，例如我們開10個進程，每個進程里開20W個線程，執行的速度理論上是比單進程開200W個線程快10倍以上的（為什麼是10倍以上而不是10倍，主要是cpu切換200W個線程的消耗肯定比切換20W個進程大得多，考慮到這部分開銷，所以是10倍以上）。
還有更好的方法嗎？答案是肯定的，它就是：
4、協程，使用它之前我們先講講what/why/how（它是什麼/為什麼用它/怎麼使用它）what：
協程是一種用戶級的輕量級線程。協程擁有自己的寄存器上下文和棧。協程調度切換時，將寄存器上下文和棧保存到其他地方，在切回來的時候，恢復先前保存的寄存器上下文和棧。因此：
協程能保留上一次調用時的狀態（即所有局部狀態的一個特定組合），每次過程重入時，就相當於進入上一次調用的狀態，換種說法：進入上一次離開時所處邏輯流的位置。
在並發編程中，協程與線程類似，每個協程表示一個執行單元，有自己的本地數據，與其它協程共享全局數據和其它資源。
why：
目前主流語言基本上都選擇了多線程作為並發設施，與線程相關的概念是搶占式多任務（Preemptive multitasking），而與協程相關的是協作式多任務。
不管是進程還是線程，每次阻塞、切換都需要陷入系統調用(system call)，先讓CPU跑操作系統的調度程序，然後再由調度程序決定該跑哪一個進程(線程)。
而且由於搶占式調度執行順序無法確定的特點，使用線程時需要非常小心地處理同步問題，而協程完全不存在這個問題（事件驅動和非同步程序也有同樣的優點）。
因為協程是用戶自己來編寫調度邏輯的，對CPU來說，協程其實是單線程，所以CPU不用去考慮怎麼調度、切換上下文，這就省去了CPU的切換開銷，所以協程在一定程度上又好於多線程。
how:
python裡面怎麼使用協程？答案是使用gevent，使用方法：看這里使用協程，可以不受線程開銷的限制，我嘗試過一次把20W條url放在單進程的協程里執行，完全沒問題。
所以最推薦的方法，是多進程+協程（可以看作是每個進程里都是單線程，而這個單線程是協程化的）多進程+協程下，避開了CPU切換的開銷，又能把多個CPU充分利用起來，這種方式對於數據量較大的爬蟲還有文件讀寫之類的效率提升是巨大的。
小例子：
#-*- coding=utf-8 -*-
import requests
from multiprocessing import Process
import gevent
from gevent import monkey; monkey.patch_all()import sys
reload(sys)
sys.setdefaultencoding('utf8')
def fetch(url):
try:
s = requests.Session()
r = s.get(url,timeout=1)#在這里抓取頁面
except Exception,e:
print e
return ''
def process_start(tasks):
gevent.joinall(tasks)#使用協程來執行
def task_start(filepath,flag = 100000):#每10W條url啟動一個進程with open(filepath,'r') as reader:#從給定的文件中讀取urlurl = reader.readline().strip()
task_list = []#這個list用於存放協程任務
i = 0 #計數器，記錄添加了多少個url到協程隊列while url!='':
i += 1
task_list.append(gevent.spawn(fetch,url,queue))#每次讀取出url，將任務添加到協程隊列if i == flag:#一定數量的url就啟動一個進程並執行p = Process(target=process_start,args=(task_list,))p.start()
task_list = [] #重置協程隊列
i = 0 #重置計數器
url = reader.readline().strip()
if task_list not []:#若退出循環後任務隊列里還有url剩餘p = Process(target=process_start,args=(task_list,))#把剩餘的url全都放到最後這個進程來執行p.start()
if __name__ == '__main__':
task_start('./testData.txt')#讀取指定文件細心的同學會發現：上面的例子中隱藏了一個問題：進程的數量會隨著url數量的增加而不斷增加，我們在這里不使用進程池multiprocessing.Pool來控制進程數量的原因是multiprocessing.Pool和gevent有沖突不能同時使用，但是有興趣的同學可以研究一下gevent.pool這個協程池。
另外還有一個問題：每個進程處理的url是累積的而不是獨立的，例如第一個進程會處理10W個，第二個進程會變成20W個，以此類推。最後定位到問題是gevent.joinall()導致的問題，有興趣的同學可以研究一下為什麼會這樣。不過這個問題的處理方案是：主進程只負責讀取url然後寫入到list中，在創建子進程的時候直接把list傳給子進程，由子進程自己去構建協程。這樣就不會出現累加的問題