① python多個線程鎖可提高效率嗎
首先，Python的多線程本身就是效率極低的，因為有GIL（Global Interpreter Lock：全局解釋鎖）機制的限制，其作用簡單說就是：對於一個解釋器，只能有一個線程在執行bytecode。
所以如果為了追求傳統意義上多線程的效率，在Python界還是用多進程（multiprocessing)吧……
這里你用了多線程，且用了鎖來控制公共資源，首先鎖這個東西會導致死鎖，不加鎖反而沒有死鎖隱患，但會有同步問題。
另外，如果不同線程操作的是不同的文件，是不存在同步問題的，如果操作同一個文件，我建議採用Queue（隊列）來處理。
總的來說，用單線程就好了，因為Python多線程本身就沒什麼效率，而且單線程也不用考慮同步問題了。非要追求效率的話，就用多進程吧，同樣也要考慮進程鎖。
② python創建多少個線程得到最優的執行效率
python因為有GIL全局解釋器鎖，所以python的多線程不能利用多核，但是如果是io密集型的項目，多線程效率也很好，我就是用多線程來做爬蟲的。
③ python的多線程是真的多線程嗎
簡單地說就是作為可能是僅有的支持多線程的解釋型語言（perl的多線程是殘疾，PHP沒有多線程），Python的多線程是有compromise的，在任意時間只有一個Python解釋器在解釋Python bytecode。
UPDATE：如評論指出，Ruby也是有thread支持的，而且至少Ruby MRI是有GIL的。
如果你的代碼是CPU密集型，多個線程的代碼很有可能是線性執行的。所以這種情況下多線程是雞肋，效率可能還不如單線程因為有context switch
但是：如果你的代碼是IO密集型，多線程可以明顯提高效率。例如製作爬蟲（我就不明白為什麼Python總和爬蟲聯系在一起…不過也只想起來這個例子…），絕大多數時間爬蟲是在等待socket返回數據。這個時候C代碼里是有release GIL的，最終結果是某個線程等待IO的時候其他線程可以繼續執行。
反過來講：你就不應該用Python寫CPU密集型的代碼…效率擺在那裡…
如果確實需要在CPU密集型的代碼里用concurrent，就去用multiprocessing庫。這個庫是基於multi process實現了類multi thread的API介面，並且用pickle部分地實現了變數共享。
再加一條，如果你不知道你的代碼到底算CPU密集型還是IO密集型，教你個方法：
multiprocessing這個mole有一個mmy的sub mole，它是基於multithread實現了multiprocessing的API。
假設你使用的是multiprocessing的Pool，是使用多進程實現了concurrency
from multiprocessing import Pool
如果把這個代碼改成下面這樣，就變成多線程實現concurrency
from multiprocessing.mmy import Pool
兩種方式都跑一下，哪個速度快用哪個就行了。
UPDATE:
剛剛才發現concurrent.futures這個東西，包含ThreadPoolExecutor和ProcessPoolExecutor，可能比multiprocessing更簡單
④ Python多線程是什麼意思
簡單地說就是作為可能是僅有的支持多線程的解釋型語言（perl的多線程是殘疾，PHP沒有多線程），Python的多線程是有compromise的，在任意時間只有一個Python解釋器在解釋Python bytecode。
UPDATE：如評論指出，Ruby也是有thread支持的，而且至少Ruby MRI是有GIL的。
如果你的代碼是CPU密集型，多個線程的代碼很有可能是線性執行的。所以這種情況下多線程是雞肋，效率可能還不如單線程因為有context switch
但是：如果你的代碼是IO密集型，多線程可以明顯提高效率。例如製作爬蟲（我就不明白為什麼Python總和爬蟲聯系在一起…不過也只想起來這個例子…），絕大多數時間爬蟲是在等待socket返回數據。這個時候C代碼里是有release GIL的，最終結果是某個線程等待IO的時候其他線程可以繼續執行。
反過來講：你就不應該用Python寫CPU密集型的代碼…效率擺在那裡…
如果確實需要在CPU密集型的代碼里用concurrent，就去用multiprocessing庫。這個庫是基於multi process實現了類multi thread的API介面，並且用pickle部分地實現了變數共享。
再加一條，如果你不知道你的代碼到底算CPU密集型還是IO密集型，教你個方法：
multiprocessing這個mole有一個mmy的sub mole，它是基於multithread實現了multiprocessing的API。
假設你使用的是multiprocessing的Pool，是使用多進程實現了concurrency
from multiprocessing import Pool
如果把這個代碼改成下面這樣，就變成多線程實現concurrency
from multiprocessing.mmy import Pool
兩種方式都跑一下，哪個速度快用哪個就行了。
UPDATE:
剛剛才發現concurrent.futures這個東西，包含ThreadPoolExecutor和ProcessPoolExecutor，可能比multiprocessing更簡單
⑤ 如何用Python做爬蟲
1）首先你要明白爬蟲怎樣工作。
想像你是一隻蜘蛛，現在你被放到了互聯「網」上。那麼，你需要把所有的網頁都看一遍。怎麼辦呢？沒問題呀，你就隨便從某個地方開始，比如說人民日報的首頁，這個叫initial pages，用$表示吧。
在人民日報的首頁，你看到那個頁面引向的各種鏈接。於是你很開心地從爬到了「國內新聞」那個頁面。太好了，這樣你就已經爬完了倆頁面（首頁和國內新聞）！暫且不用管爬下來的頁面怎麼處理的，你就想像你把這個頁面完完整整抄成了個html放到了你身上。
突然你發現， 在國內新聞這個頁面上，有一個鏈接鏈回「首頁」。作為一隻聰明的蜘蛛，你肯定知道你不用爬回去的吧，因為你已經看過了啊。所以，你需要用你的腦子，存下你已經看過的頁面地址。這樣，每次看到一個可能需要爬的新鏈接，你就先查查你腦子里是不是已經去過這個頁面地址。如果去過，那就別去了。
好的，理論上如果所有的頁面可以從initial page達到的話，那麼可以證明你一定可以爬完所有的網頁。
那麼在python里怎麼實現呢？
很簡單
import Queue
initial_page = "初始化頁"
url_queue = Queue.Queue()
seen = set()
seen.insert(initial_page)
url_queue.put(initial_page)
while(True): #一直進行直到海枯石爛
if url_queue.size()>0:
current_url = url_queue.get() #拿出隊例中第一個的url
store(current_url) #把這個url代表的網頁存儲好
for next_url in extract_urls(current_url): #提取把這個url里鏈向的url
if next_url not in seen:
seen.put(next_url)
url_queue.put(next_url)
else:
break
寫得已經很偽代碼了。
所有的爬蟲的backbone都在這里，下面分析一下為什麼爬蟲事實上是個非常復雜的東西——搜索引擎公司通常有一整個團隊來維護和開發。
2）效率
如果你直接加工一下上面的代碼直接運行的話，你需要一整年才能爬下整個豆瓣的內容。更別說Google這樣的搜索引擎需要爬下全網的內容了。
問題出在哪呢？需要爬的網頁實在太多太多了，而上面的代碼太慢太慢了。設想全網有N個網站，那麼分析一下判重的復雜度就是N*log(N)，因為所有網頁要遍歷一次，而每次判重用set的話需要log(N)的復雜度。OK，OK，我知道python的set實現是hash——不過這樣還是太慢了，至少內存使用效率不高。
通常的判重做法是怎樣呢？Bloom Filter. 簡單講它仍然是一種hash的方法，但是它的特點是，它可以使用固定的內存（不隨url的數量而增長）以O(1)的效率判定url是否已經在set中。可惜天下沒有白吃的午餐，它的唯一問題在於，如果這個url不在set中，BF可以100%確定這個url沒有看過。但是如果這個url在set中，它會告訴你：這個url應該已經出現過，不過我有2%的不確定性。注意這里的不確定性在你分配的內存足夠大的時候，可以變得很小很少。一個簡單的教程:Bloom Filters by Example
注意到這個特點，url如果被看過，那麼可能以小概率重復看一看（沒關系，多看看不會累死）。但是如果沒被看過，一定會被看一下（這個很重要，不然我們就要漏掉一些網頁了！）。 [IMPORTANT: 此段有問題，請暫時略過]
好，現在已經接近處理判重最快的方法了。另外一個瓶頸——你只有一台機器。不管你的帶寬有多大，只要你的機器下載網頁的速度是瓶頸的話，那麼你只有加快這個速度。用一台機子不夠的話——用很多台吧！當然，我們假設每台機子都已經進了最大的效率——使用多線程（python的話，多進程吧）。
3）集群化抓取
爬取豆瓣的時候，我總共用了100多台機器晝夜不停地運行了一個月。想像如果只用一台機子你就得運行100個月了...
那麼，假設你現在有100台機器可以用，怎麼用python實現一個分布式的爬取演算法呢？
我們把這100台中的99台運算能力較小的機器叫作slave，另外一台較大的機器叫作master，那麼回顧上面代碼中的url_queue，如果我們能把這個queue放到這台master機器上，所有的slave都可以通過網路跟master聯通，每當一個slave完成下載一個網頁，就向master請求一個新的網頁來抓取。而每次slave新抓到一個網頁，就把這個網頁上所有的鏈接送到master的queue里去。同樣，bloom filter也放到master上，但是現在master只發送確定沒有被訪問過的url給slave。Bloom Filter放到master的內存里，而被訪問過的url放到運行在master上的Redis里，這樣保證所有操作都是O(1)。（至少平攤是O(1)，Redis的訪問效率見:LINSERT – Redis)
考慮如何用python實現：
在各台slave上裝好scrapy，那麼各台機子就變成了一台有抓取能力的slave，在master上裝好Redis和rq用作分布式隊列。
代碼於是寫成
#slave.py
current_url = request_from_master()
to_send = []
for next_url in extract_urls(current_url):
to_send.append(next_url)
store(current_url);
send_to_master(to_send)
#master.py
distributed_queue = DistributedQueue()
bf = BloomFilter()
initial_pages = "www.renmingribao.com"
while(True):
if request == 'GET':
if distributed_queue.size()>0:
send(distributed_queue.get())
else:
break
elif request == 'POST':
bf.put(request.url)
好的，其實你能想到，有人已經給你寫好了你需要的：darkrho/scrapy-redis · GitHub
4）展望及後處理
雖然上面用很多「簡單」，但是真正要實現一個商業規模可用的爬蟲並不是一件容易的事。上面的代碼用來爬一個整體的網站幾乎沒有太大的問題。
但是如果附加上你需要這些後續處理，比如
有效地存儲（資料庫應該怎樣安排）
有效地判重（這里指網頁判重，咱可不想把人民日報和抄襲它的大民日報都爬一遍）
有效地信息抽取（比如怎麼樣抽取出網頁上所有的地址抽取出來，「朝陽區奮進路中華道」），搜索引擎通常不需要存儲所有的信息，比如圖片我存來幹嘛...
及時更新（預測這個網頁多久會更新一次）
如你所想，這里每一個點都可以供很多研究者十數年的研究。雖然如此，
「路漫漫其修遠兮,吾將上下而求索」。
所以，不要問怎麼入門，直接上路就好了：）
⑥ python多線程能提高效率嗎
很多爬蟲工作者都遇到過抓取速度非常慢，現在的大多數網站都具備了反爬蟲技術，對IP的訪問頻率限制很嚴格。如果想提升爬蟲的速度，大家可以嘗試以下方法。
一、盡量減少訪問次數。
單次爬蟲任務的大多耗時在網路請求等待響應，所以能減少網路請求就盡量減少請求，這樣既能減少目標網站的壓力，也能減少代理伺服器的壓力，提高工作效率。
二、精簡流程，減少重復。
大部分網站並不是嚴格意義上的樹狀結構，而是多重交叉的網狀結構，所以從多個入口深入的網頁會有很多重復，一般根據URL或者ID進行唯一性判別，爬過的就不需要再爬。一些數據如果可以在一個頁面內獲取到，也可以在多個頁面下獲取到，那就選擇只在一個頁面內獲取。
三、多線程任務。
大量爬蟲是一個IO阻塞的任務，所以採用多線程的並發方式可以有效地提高整體速度。多線程可以更好地提高資源利用率，程序設計也更加堅定，程序響應也更快。
四、分布式任務。
上面三點都做到極致了，但是單機單位時間內能爬取到的網頁數量還不足以達到目標，在指定時間內還不能及時的完成任務，那麼就只能多機器來同時進行爬蟲任務了，這就是分布式爬蟲。
做好以上幾點，基本可以將爬蟲的效率提升大半，另外爬蟲代理ip也是不可缺少的尤其是對於量大的任務，IPIDEA提供全球ip的同時更注重保護數據的安全，也可以減少反爬蟲策略的觸發，一舉多得。
⑦ python 爬蟲 多進程 多線程 哪個好
看你更喜歡哪個，都差不多的話，python的優勢是跨平台很好，庫很全，但是效率沒有node.js好。 所以如果小爬蟲就python，大規模的用node吧
⑧ 請教一個問題，怎麼提高 python 爬蟲的爬取效率
很多爬蟲工作者都遇到過抓取非常慢的問題，尤其是需要採集大量數據的情況下。那麼如何提高爬蟲採集效率就十分關鍵，一塊了解如何提高爬蟲採集效率問題。
1.盡可能減少網站訪問次數
單次爬蟲的主要把時間消耗在網路請求等待響應上面，所以能減少網站訪問就減少網站訪問，既減少自身的工作量，也減輕網站的壓力，還降低被封的風險。
第一步要做的就是流程優化，盡量精簡流程，避免在多個頁面重復獲取。
隨後去重，同樣是十分重要的手段，一般根據url或者id進行唯一性判別，爬過的就不再繼續爬了。
2.分布式爬蟲
即便把各種法子都用盡了，單機單位時間內能爬的網頁數仍是有限的，面對大量的網頁頁面隊列，可計算的時間仍是很長，這種情況下就必須要用機器換時間了，這就是分布式爬蟲。
第一步，分布式並不是爬蟲的本質，也並不是必須的，對於互相獨立、不存在通信的任務就可手動對任務分割，隨後在多個機器上各自執行，減少每台機器的工作量，費時就會成倍減少。
例如有200W個網頁頁面待爬，可以用5台機器各自爬互不重復的40W個網頁頁面，相對來說單機費時就縮短了5倍。
可是如果存在著需要通信的狀況，例如一個變動的待爬隊列，每爬一次這個隊列就會發生變化，即便分割任務也就有交叉重復，因為各個機器在程序運行時的待爬隊列都不一樣了——這種情況下只能用分布式，一個Master存儲隊列，其他多個Slave各自來取，這樣共享一個隊列，取的情況下互斥也不會重復爬取。IPIDEA提供高匿穩定的IP同時更注重用戶隱私的保護，保障用戶的信息安全。含有240＋國家地區的ip，支持API批量使用，支持多線程高並發使用。
⑨ 為什麼有人說 Python 的多線程是雞肋
如果你的代碼是CPU密集型，多個線程的代碼很有可能是線性執行的。所以這種情況下多線程是雞肋，效率可能還不如單線程因為有context switch
但是：如果你的代碼是IO密集型，多線程可以明顯提高效率。例如製作爬蟲（我就不明白為什麼Python總和爬蟲聯系在一起…不過也只想起來這個例子…），絕大多數時間爬蟲是在等待socket返回數據。這個時候C代碼里是有release GIL的，最終結果是某個線程等待IO的時候其他線程可以繼續執行。
反過來講：你就不應該用Python寫CPU密集型的代碼…效率擺在那裡…如果確實需要在CPU密集型的代碼里用concurrent，就去用multiprocessing庫。這個庫是基於multi process實現了類multi thread的API介面，並且用pickle部分地實現了變數共享。
作者：yegle
鏈接：https://www.hu.com/question/23474039/answer/24695447
來源：知乎