Python3.2中引入的concurrent非常的好用，只用幾行代碼就可以編寫出線程池/進程池，并且計算型任務效率和mutiprocessing.pool提供的poll和ThreadPoll相比不分伯仲，而且在IO型任務由于引入了Future的概念效率要高數倍。

而threading的話還要自己維護相關的隊列防止死鎖，代碼的可讀性也會下降，相反concurrent提供的線程池卻非常的便捷，不用自己操心死鎖以及編寫線程池代碼，由于異步的概念IO型任務也更有優勢。

既然如此，如果不是為了向下兼容2.x，是不是可以完全沒有必要繼續使用mutiprocessing和threading了？concurrent如此的優秀。

?

concurrent的確很好用，主要提供了ThreadPoolExecutor和ProcessPoolExecutor。一個多線程，一個多進程。但concurrent本質上都是對threading和mutiprocessing的封裝。看它的源碼可以知道。
ThreadPoolExecutor自己提供了任務隊列，不需要自己寫了。而所謂的線程池，它只是簡單的比較當前的threads數量和定義的max_workers的大小，小于max_workers就允許任務創建線程執行任務。可以看源碼

def _adjust_thread_count(self):# When the executor gets lost, the weakref callback will wake up# the worker threads.def weakref_cb(_, q=self._work_queue):q.put(None)# TODO(bquinlan): Should avoid creating new threads if there are more# idle threads than items in the work queue.if len(self._threads) < self._max_workers:t = threading.Thread(target=_worker,args=(weakref.ref(self, weakref_cb),self._work_queue))t.daemon = Truet.start()self._threads.add(t)_threads_queues[t] = self._work_queue

所以如果你自己維護隊列的話也沒問題，cocurrent內部也是自己維護了一個隊列，它給你寫好了而已。
至于死鎖問題concurrent也會引起死鎖的問題。給你一個例子，運行看看

import time from concurrent.futures import ThreadPoolExecutordef wait_on_b():time.sleep(5)print(b.result()) # b will never complete because it is waiting on a.return 5def wait_on_a():time.sleep(5)print(a.result()) # a will never complete because it is waiting on b.return 6executor = ThreadPoolExecutor(max_workers=2) a = executor.submit(wait_on_b) b = executor.submit(wait_on_a)

ProcessPoolExecutor 內部也是使用的mutiprocessing。能夠從充分利用多核的特性，擺脫GIL的限制。注意定義ProcessPoolExecutor(max_workers=2)的時候max_workers稍大于CPU的核數，不能太大。ProcessPoolExecutor內部維持了一個call_queue用于保持任務隊列，其類型是multiprocessing.Queue。還有一個管理隊列的線程。這可以說是cocurrent的一個優化。
具體可以看源碼，self._adjust_process_count()其實就是開啟進程執行任務，點進去_adjust_process_count一看就知道。self._queue_management_thread是管理隊列的線程

if self._queue_management_thread is None:# Start the processes so that their sentinels are known. self._adjust_process_count()self._queue_management_thread = threading.Thread(target=_queue_management_worker,args=(weakref.ref(self, weakref_cb),self._processes,self._pending_work_items,self._work_ids,self._call_queue,self._result_queue))self._queue_management_thread.daemon = Trueself._queue_management_thread.start()_threads_queues[self._queue_management_thread] = self._result_queue

所以說cocurrent好用，就是它自己做了一些更好的處理，譬如維持隊列，管理隊列線程，不需要你再操心。當然你也可以自己實現。你能用cocurrent實現的。用threading和mutiprocessing都能實現，大不了自己再做些額外的工作。因為cocurrent本質上核心也是用的這2個。當然有了現成的更好的cocurrent最好了，直接拿來使用，省的自己再造輪子。所以說用哪個看個人熟悉程度，譬如我用的python2,就用不了cocurrent。只好用threading。

轉載于:https://www.cnblogs.com/tcppdu/p/10546939.html

總結

以上是生活随笔為你收集整理的Python有了concurrent的话mutiprocessing和threading还有存在的意义吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。