python不支持多線程

1. 為什麼有人說 python 的多線程是雞肋

Python多線程最多佔用一個邏輯核心。
如果你每個線程都是io密集型（阻塞多於計算），也就是說單獨一個線程幾乎大段時間沒事兒干，不能充分利用cpu，那可能多線程跑在一個核心上還有意義；
如果每個線程都是計算密集型（幾乎都是計算任務），那一般情況1個線程就可以充分利用一個邏輯核心，多個線程反而增加了切換開銷。從這個角度上說Python的多線程確實雞肋。
多進程可以解決這個問題，因為進程不是由Python管理的，而是由系統管理的，系統會合理分配CPU資源。

2. 為什麼有人說 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更簡單

3. 為什麼有人說 Python 的多線程是雞肋呢

由於python是一種解釋性腳本語言，因此運行過程中始終存在全局線程鎖。
簡單的來說就是在實際的運行過程中，python只能利用一個線程，因此python的多線程並不達到C語言多線程的性能。

建議使用多進程來代替多線程，但需要注意的是多進程最好不要涉及到例如文件操作的頻繁操作IO的功能。

4. 為什麼有人說 Python 的多線程是雞肋

因為 Python 中臭名昭著的 GIL。

那麼 GIL 是什麼？為什麼會有 GIL？多線程真的是雞肋嗎？ GIL 可以去掉嗎？帶著這些問題，我們一起往下看，同時需要你有一點點耐心。

多線程是不是雞肋，我們先做個實驗，實驗非常簡單，就是將數字 「1億」 遞減，減到 0 程序就終止，這個任務如果我們使用單線程來執行，完成時間會是多少？使用多線程又會是多少？show me the code

那麼把 GIL 去掉可行嗎？

還真有人這么干多，但是結果令人失望，在1999年Greg Stein 和Mark Hammond 兩位哥們就創建了一個去掉 GIL 的 Python 分支，在所有可變數據結構上把 GIL 替換為更為細粒度的鎖。然而，做過了基準測試之後，去掉GIL的 Python 在單線程條件下執行效率將近慢了2倍。

Python之父表示：基於以上的考慮，去掉GIL沒有太大的價值而不必花太多精力。

5. 為什麼有人說 Python 的多線程是雞肋

多線程還是有用的，多進程有多進程的好處，多線程有多線程的好處。
多進程穩定，啟動時開銷大點，但如果你的運行時間遠大於多進程的時間，用多進程比較方便，如postgresql用多進程，chrome 多進程。
如果你只是想做個定時器樣的簡單東西，對穩定性要求低些，如vb,c#類似的定時器，用多線程吧，但線程的同步要注意了。python的線程更加類似定時器，python的線程不是真線程，但有的場合用這種定時器也能解決很多問題，因為開銷小，開啟也方便。
進程和線程，一個是重量級的，一個輕量級的，重量級的進程有保護區，進程上下文都是操作系統保護的，而線程是自己管理，需要一定的技術，不能保證在並發時的穩定性（多進程也不穩定，但很容易看出來，因為多出了進程容易發現），而python的更像是定時器，定時器有時也可以模擬線程，定時器多時的開銷比線程的開銷要小，真線程有下上文開銷，一個操作系統啟動多進程和多線程會達到切換飽和是有數量的，真線程或進程太多都會導致cpu佔用率居高不下，而定時器可以開n多。
很多東西不是一種比另外一種先進，而是一種互補的關系，計算機的計算單位切換有優點必有缺點，關鍵在找到合適的使用方式揚長避短。

6. 為什麼我的python多線程不能交替運行

不會,python目前不適應運行在多核上的多線程。僅能使用單核,如果需要多核你可以考慮多進程方式。

7. 為什麼說Python沒有真正意義上的多線程

因為python解釋器同一個時間只能使用一個cpu，所以再多的線程還是使用同一個cpu
真正的多線程是充分利用多個cpu的計算能力的

8. pyhon多線程無效，不知問題出現在哪裡

在python里線程出問題，可能會導致主進程崩潰。 雖然python里的線程是操作系統的真實線程。
那麼怎麼解決呢？通過我們用進程方式。子進程崩潰後，會完全的釋放所有的內存和錯誤狀態。所以進程更安全。 另外通過進程，python可以很好的繞過GIL，這個全局鎖問題。
但是進程也是有局限的。不要建立超過CPU總核數的進程，否則效率也不高。
簡單的總結一下。
當我們想實現多任務處理時，首先要想到使用multiprocessing， 但是如果覺著進程太笨重，那麼就要考慮使用線程。 如果多任務處理中需要處理的太多了，可以考慮多進程，每個進程再採用多線程。如果還處理不要，就要使用輪詢模式，比如使用poll event, twisted等方式。如果是GUI方式，則要通過事件機制，或者是消息機制處理，GUI使用單線程。
所以在python里線程不要盲目用， 也不要濫用。 但是線程不安全是事實。如果僅僅是做幾個後台任務，則可以考慮使用守護線程做。如果需要做一些危險操作，可能會崩潰的，就用子進程去做。 如果需要高度穩定性，同時並發數又不高的服務。則強烈建議用多進程的multiprocessing模塊實現。
在linux或者是unix里，進程的使用代價沒有windows高。還是可以接受的。

9. 為什麼有人說 Python 的多線程是雞肋呢

首先，我並不認同這個觀點，我覺得覺得Python 的多線程是雞肋多餘的人，應該還沒有完全使用過Python 的多線程功能，並沒有發掘它的潛在能力。

• 什麼是Python多線程

Python多線程最大的優點就是使用方便，很多時候我們並不需要做大量的密集型數據的處理運算，這時候用Python多線程是最方便快捷的，可以大大減少工作量、提高工作效率。

• 總結

從以上幾點我們就可以看出，Python多線程並不雞肋，只是有時候使用者在不巧當的地方使用，它自然不是那麼順手，我們加深熟悉了解Python多線程的適用范圍。

10. 為什麼有人說 Python 的多線程是雞肋

說這句話的人一定是在網上看到一些資料說，python的多線程不支持多核計算的，幾乎不會提高運行效率。其實這句話只是對於CPython。因為CPython中存在GIL鎖，每次只能有一個線程可以訪問位元組碼。這樣，即便線程再多，即便多核，線程都不可能同時執行，因為位元組碼一個時刻只能由一個線程訪問。

參考官方資料：
Global interpreter lock
The mechanism used by the CPython interpreter to assure that only one thread executes Python bytecode at a time. This simplifies the CPython implementation by making the object model (including critical built-in types such as dict) implicitly safe against concurrent access. Locking the entire interpreter makes it easier for the interpreter to be multi-threaded, at the expense of much of the parallelism afforded by multi-processor machines.
However, some extension moles, either standard or third-party, are designed so as to release the GIL when doing computationally-intensive tasks such as compression or hashing. Also, the GIL is always released when doing I/O.
Past efforts to create a 「free-threaded」 interpreter (one which locks shared data at a much finer granularity) have not been successful because performance suffered in the common single-processor case. It is believed that overcoming this performance issue would make the implementation much more complicated and therefore costlier to maintain.