python多線程event

⑴ python多線程的問題如何處理

在python里線程出問題，可能會導致主進程崩潰。 雖然python里的線程是操作系統的真實線程。

那麼怎麼解決呢？通過我們用進程方式。子進程崩潰後，會完全的釋放所有的內存和錯誤狀態。所以進程更安全。 另外通過進程，python可以很好的繞過GIL，這個全局鎖問題。

但是進程也是有局限的。不要建立超過CPU總核數的進程，否則效率也不高。

簡單的總結一下。
當我們想實現多任務處理時，首先要想到使用multiprocessing， 但是如果覺著進程太笨重，那麼就要考慮使用線程。 如果多任務處理中需要處理的太多了，可以考慮多進程，每個進程再採用多線程。如果還處理不要，就要使用輪詢模式，比如使用poll event, twisted等方式。如果是GUI方式，則要通過事件機制，或者是消息機制處理，GUI使用單線程。

所以在python里線程不要盲目用， 也不要濫用。 但是線程不安全是事實。如果僅僅是做幾個後台任務，則可以考慮使用守護線程做。如果需要做一些危險操作，可能會崩潰的，就用子進程去做。 如果需要高度穩定性，同時並發數又不高的服務。則強烈建議用多進程的multiprocessing模塊實現。

在linux或者是unix里，進程的使用代價沒有windows高。還是可以接受的。

⑵ Python怎麼多線程中添加協程

由於python是一種解釋性腳本語言，python的多線程在運行過程中始終存在全局線程鎖。
簡單的來說就是在實際的運行過程中，python只能利用一個線程，因此python的多線程並不達到C語言多線程的性能。
可以使用多進程來代替多線程，但需要注意的是多進程最好不要涉及到例如文件操作的頻繁操作IO的功能。

⑶ 請教python如何開啟多線程

可以定義函數把這些代碼放在不同的函數里，然後threading模塊
import threading
th1 = threading.Thread(target=func1, args=(arg1, arg2, ...))
照這樣再定義別的線程，開啟用Thread類的start方法
th1.start(); th2.start(); ...

⑷ 為什麼有人說 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沒有太大的價值而不必花太多精力。

⑸ python之多線程原理

並發：邏輯上具備同時處理多個任務的能力。
並行：物理上在同一時刻執行多個並發任務。

舉例：開個QQ，開了一個進程，開了微信，開了一個進程。在QQ這個進程裡面，傳輸文字開一個線程、傳輸語音開了一個線程、彈出對話框又開了一個線程。
總結：開一個軟體，相當於開了一個進程。在這個軟體運行的過程里，多個工作同時運轉，完成了QQ的運行，那麼這個多個工作分別有多個線程。

線程和進程之間的區別：

進程在python中的使用，對模塊threading進行操作，調用的這個三方庫。可以通過 help(threading) 了解其中的方法、變數使用情況。也可以使用 dir(threading) 查看目錄結構。

current_thread_num = threading.active_count() # 返回正在運行的線程數量
run_thread_len = len(threading.enumerate()) # 返回正在運行的線程數量
run_thread_list = threading.enumerate() # 返回當前運行線程的列表
t1=threading.Thread(target=dance) #創建兩個子線程，參數傳遞為函數名
t1.setDaemon(True) # 設置守護進程，守護進程：主線程結束時自動退出子線程。
t1.start() # 啟動子線程
t1.join() # 等待進程結束 exit()`# 主線程退出，t1子線程設置了守護進程，會自動退出。其他子線程會繼續執行。

⑹ python 怎麼實現多線程的

線程也就是輕量級的進程，多線程允許一次執行多個線程，Python是多線程語言，它有一個多線程包，GIL也就是全局解釋器鎖，以確保一次執行單個線程，一個線程保存GIL並在將其傳遞給下一個線程之前執行一些操作，也就產生了並行執行的錯覺。

⑺ Python非同步編程全攻略

如果你厭倦了多線程，不妨試試python的非同步編程，再引入async, await關鍵字之後語法變得更加簡潔和直觀，又經過幾年的生態發展，現在是一個很不錯的並發模型。

下面介紹一下python非同步編程的方方面面。

因為GIL的存在，所以Python的多線程在CPU密集的任務下顯得無力，但是對於IO密集的任務，多線程還是足以發揮多線程的優勢的，而非同步也是為了應對IO密集的任務，所以兩者是一個可以相互替代的方案，因為設計的不同，理論上非同步要比多線程快，因為非同步的花銷更少, 因為不需要額外系統申請額外的內存，而線程的創建跟系統有關，需要分配一定量的內存，一般是幾兆，比如linux默認是8MB。

雖然非同步很好，比如可以使用更少的內存，比如更好地控制並發(也許你並不這么認為:))。但是由於async/await 語法的存在導致與之前的語法有些割裂，所以需要適配，需要付出額外的努力，再者就是生態遠遠沒有同步編程強大，比如很多庫還不支持非同步，所以你需要一些額外的適配。

為了不給其他網站帶來困擾，這里首先在自己電腦啟動web服務用於測試，代碼很簡單。

本文所有依賴如下:

所有依賴可通過代碼倉庫的requirements.txt一次性安裝。

首先看一個錯誤的例子

輸出如下:

發現花費了3秒，不符合預期呀。。。。這是因為雖然用了協程，但是每個協程是串列的運行，也就是說後一個等前一個完成之後才開始，那麼這樣的非同步代碼並沒有並發，所以我們需要讓這些協程並行起來

為了讓代碼變動的不是太多，所以這里用了一個笨辦法來等待所有任務完成, 之所以在main函數中等待是為了不讓ClientSession關閉, 如果你移除了main函數中的等待代碼會發現報告異常 RuntimeError: Session is closed ,而代碼里的解決方案非常的不優雅，需要手動的等待，為了解決這個問題，我們再次改進代碼。

這里解決的方式是通過 asyncio.wait 方法等待一個協程列表，默認是等待所有協程結束後返回，會返回一個完成(done)列表，以及一個待辦(pending)列表。

如果我們不想要協程對象而是結果，那麼我們可以使用 asyncio.gather

結果輸出如下:

通過 asyncio.ensure_future 我們就能創建一個協程，跟調用一個函數差別不大，為了等待所有任務完成之後退出，我們需要使用 asyncio.wait 等方法來等待，如果只想要協程輸出的結果，我們可以使用 asyncio.gather 來獲取結果。

雖然前面能夠隨心所欲的創建協程，但是就像多線程一樣，我們也需要處理協程之間的同步問題，為了保持語法及使用情況的一致，多線程中用到的同步功能，asyncio中基本也能找到, 並且用法基本一致，不一致的地方主要是需要用非同步的關鍵字，比如 async with/ await 等

通過鎖讓並發慢下來，讓協程一個一個的運行。

輸出如下:

通過觀察很容易發現，並發的速度因為鎖而慢下來了，因為每次只有一個協程能獲得鎖，所以並發變成了串列。

通過事件來通知特定的協程開始工作，假設有一個任務是根據http響應結果選擇是否激活。

輸出如下:

可以看到事件(Event)等待者都是在得到響應內容之後輸出，並且事件(Event)可以是多個協程同時等待。

上面的事件雖然很棒，能夠在不同的協程之間同步狀態，並且也能夠一次性同步所有的等待協程，但是還不夠精細化，比如想通知指定數量的等待協程，這個時候Event就無能為力了，所以同步原語中出現了Condition。

輸出如下:

可以看到，前面兩個等待的協程是在同一時刻完成，而不是全部等待完成。

通過創建協程的數量來控制並發並不是非常優雅的方式，所以可以通過信號量的方式來控制並發。

輸出如下:

可以發現，雖然同時創建了三個協程，但是同一時刻只有兩個協程工作，而另外一個協程需要等待一個協程讓出信號量才能運行。

無論是協程還是線程，任務之間的狀態同步還是很重要的，所以有了應對各種同步機制的同步原語，因為要保證一個資源同一個時刻只能一個任務訪問，所以引入了鎖，又因為需要一個任務等待另一個任務，或者多個任務等待某個任務，因此引入了事件(Event)，但是為了更精細的控制通知的程度，所以又引入了條件(Condition), 通過條件可以控制一次通知多少的任務。

有時候的並發需求是通過一個變數控制並發任務的並發數而不是通過創建協程的數量來控制並發，所以引入了信號量(Semaphore)，這樣就可以在創建的協程數遠遠大於並發數的情況下讓協程在指定的並發量情況下並發。

不得不承認非同步編程相比起同步編程的生態要小的很多，所以不可能完全非同步編程，因此需要一種方式兼容。

多線程是為了兼容同步得代碼。

多進程是為了利用CPU多核的能力。

輸出如下:

可以看到總耗時1秒，說明所有的線程跟進程是同時運行的。

下面是本人使用過的一些非同步庫，僅供參考

web框架

http客戶端

資料庫

ORM

雖然非同步庫發展得還算不錯，但是中肯的說並沒有覆蓋方方面面。

雖然我鼓勵大家嘗試非同步編程，但是本文的最後卻是讓大家謹慎的選擇開發環境，如果你覺得本文的並發，同步，兼容多線程，多進程不值得一提，那麼我十分推薦你嘗試以非同步編程的方式開始一個新的項目，如果你對其中一些還有疑問或者你確定了要使用的依賴庫並且大多數是沒有非同步庫替代的，那麼我還是建議你直接按照自己擅長的同步編程開始。

非同步編程雖然很不錯，不過，也許你並不需要。