python多線程假的
Ⅰ 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多進程和多線程的區別
進程是程序（軟體，應用）的一個執行實例，每個運行中的程序，可以同時創建多個進程，但至少要有一個。每個進程都提供執行程序所需的所有資源，都有一個虛擬的地址空間、可執行的代碼、操作系統的介面、安全的上下文（記錄啟動該進程的用戶和許可權等等）、唯一的進程ID、環境變數、優先順序類、最小和最大的工作空間（內存空間）。進程可以包含線程，並且每個進程必須有至少一個線程。每個進程啟動時都會最先產生一個線程，即主線程，然後主線程會再創建其他的子線程。
線程，有時被稱為輕量級進程(Lightweight Process，LWP），是程序執行流的最小單元。一個標準的線程由線程ID，當前指令指針(PC），寄存器集合和堆棧組成。另外，線程是進程中的一個實體，是被系統獨立調度和分派的基本單位，線程自己不獨立擁有系統資源，但它可與同屬一個進程的其它線程共享該進程所擁有的全部資源。每一個應用程序都至少有一個進程和一個線程。在單個程序中同時運行多個線程完成不同的被劃分成一塊一塊的工作，稱為多線程。
舉個例子，某公司要生產一種產品，於是在生產基地建設了很多廠房，每個廠房內又有多條流水生產線。所有廠房配合將整個產品生產出來，單個廠房內的流水線負責生產所屬廠房的產品部件，每個廠房都擁有自己的材料庫，廠房內的生產線共享這些材料。公司要實現生產必須擁有至少一個廠房一條生產線。換成計算機的概念，那麼這家公司就是應用程序，廠房就是應用程序的進程，生產線就是某個進程的一個線程。
線程的特點：
線程是一個execution context（執行上下文），即一個cpu執行時所需要的一串指令。假設你正在讀一本書，沒有讀完，你想休息一下，但是你想在回來時繼續先前的進度。有一個方法就是記下頁數、行數與字數這三個數值，這些數值就是execution context。如果你的室友在你休息的時候，使用相同的方法讀這本書。你和她只需要這三個數字記下來就可以在交替的時間共同閱讀這本書了。
線程的工作方式與此類似。CPU會給你一個在同一時間能夠做多個運算的幻覺，實際上它在每個運算上只花了極少的時間，本質上CPU同一時刻只能幹一件事，所謂的多線程和並發處理只是假象。CPU能這樣做是因為它有每個任務的execution context，就像你能夠和你朋友共享同一本書一樣。
進程與線程區別：
同一個進程中的線程共享同一內存空間，但進程之間的內存空間是獨立的。
同一個進程中的所有線程的數據是共享的，但進程之間的數據是獨立的。
對主線程的修改可能會影響其他線程的行為，但是父進程的修改（除了刪除以外）不會影響其他子進程。
線程是一個上下文的執行指令，而進程則是與運算相關的一簇資源。
同一個進程的線程之間可以直接通信，但是進程之間的交流需要藉助中間代理來實現。
創建新的線程很容易，但是創建新的進程需要對父進程做一次復制。
一個線程可以操作同一進程的其他線程，但是進程只能操作其子進程。
線程啟動速度快，進程啟動速度慢（但是兩者運行速度沒有可比性）。
由於現代cpu已經進入多核時代，並且主頻也相對以往大幅提升，多線程和多進程編程已經成為主流。Python全面支持多線程和多進程編程，同時還支持協程。
Ⅲ 關於python多線程的一些問題。
創建的子線程默認是非守護的。
非守護：當主線程結束時，子線程繼續運行，二者互不影響。
子線程是守護線程：當主線程結束時，子線程也結束（不管子線程工作有沒有完成）。
join作用是線程同步，是讓主線程等待子線程結束才結束（主線程完成工作了也不結束，阻塞等待，等子線程完成其工作才一起結束）。
相信此時你已經懂你的兩個問題了。
沒加join的時候主線程結束了，所以命令提示符>>>就出來了，可是子線程還沒結束，過了3/5秒後列印了字元串。加了join後主線程等兩個子線程都結束才一起結束，所以最後才出來>>>。
理解確實有點偏差。守護是指子線程守護著主線程，你死我也死，謂之守護。
Ⅳ Python實現簡單多線程任務隊列
Python實現簡單多線程任務隊列
最近我在用梯度下降演算法繪制神經網路的數據時，遇到了一些演算法性能的問題。梯度下降演算法的代碼如下（偽代碼）：
defgradient_descent(): # the gradient descent code plotly.write(X, Y)
一般來說，當網路請求 plot.ly 繪圖時會阻塞等待返回，於是也會影響到其他的梯度下降函數的執行速度。
一種解決辦法是每調用一次 plotly.write 函數就開啟一個新的線程，但是這種方法感覺不是很好。 我不想用一個像 cerely（一種分布式任務隊列）一樣大而全的任務隊列框架，因為框架對於我的這點需求來說太重了，並且我的繪圖也並不需要 redis 來持久化數據。
那用什麼辦法解決呢？我在 python 中寫了一個很小的任務隊列，它可以在一個單獨的線程中調用 plotly.write函數。下面是程序代碼。
classTaskQueue(Queue.Queue):
首先我們繼承 Queue.Queue 類。從 Queue.Queue 類可以繼承 get 和 put 方法，以及隊列的行為。
def__init__(self, num_workers=1): Queue.Queue.__init__(self) self.num_workers=num_workers self.start_workers()
初始化的時候，我們可以不用考慮工作線程的數量。
defadd_task(self, task,*args,**kwargs): args=argsor() kwargs=kwargsor{} self.put((task, args, kwargs))
我們把 task, args, kwargs 以元組的形式存儲在隊列中。*args 可以傳遞數量不等的參數，**kwargs 可以傳遞命名參數。
defstart_workers(self): foriinrange(self.num_workers): t=Thread(target=self.worker) t.daemon=True t.start()
我們為每個 worker 創建一個線程，然後在後台刪除。
下面是 worker 函數的代碼：
defworker(self): whileTrue: tupl=self.get() item, args, kwargs=self.get() item(*args,**kwargs) self.task_done()
worker 函數獲取隊列頂端的任務，並根據輸入參數運行，除此之外，沒有其他的功能。下面是隊列的代碼：
我們可以通過下面的代碼測試：
defblokkah(*args,**kwargs): time.sleep(5) print「Blokkah mofo!」 q=TaskQueue(num_workers=5) foriteminrange(1): q.add_task(blokkah) q.join()# wait for all the tasks to finish. print「Alldone!」
Blokkah 是我們要做的任務名稱。隊列已經緩存在內存中，並且沒有執行很多任務。下面的步驟是把主隊列當做單獨的進程來運行，這樣主程序退出以及執行資料庫持久化時，隊列任務不會停止運行。但是這個例子很好地展示了如何從一個很簡單的小任務寫成像工作隊列這樣復雜的程序。
defgradient_descent(): # the gradient descent code queue.add_task(plotly.write, x=X, y=Y)
修改之後，我的梯度下降演算法工作效率似乎更高了。如果你很感興趣的話，可以參考下面的代碼。 classTaskQueue(Queue.Queue): def__init__(self, num_workers=1):Queue.Queue.__init__(self)self.num_workers=num_workersself.start_workers() defadd_task(self, task,*args,**kwargs):args=argsor()kwargs=kwargsor{}self.put((task, args, kwargs)) defstart_workers(self):foriinrange(self.num_workers):t=Thread(target=self.worker)t.daemon=Truet.start() defworker(self):whileTrue:tupl=self.get()item, args, kwargs=self.get()item(*args,**kwargs)self.task_done() deftests():defblokkah(*args,**kwargs):time.sleep(5)print"Blokkah mofo!" q=TaskQueue(num_workers=5) foriteminrange(10):q.add_task(blokkah) q.join()# block until all tasks are doneprint"All done!" if__name__=="__main__":tests()