python之當前GIL設計的缺陷

基于pcode數量的調度方式

按照Python社區的想法，操作系統本身的線程調度已經非常成熟穩定了，沒有必要自己搞一套。所以Python的線程就是C語言的一個pthread，并通過操作系統調度算法進行調度(例如linux是CFS)。為了讓各個線程能夠平均利用CPU時間，python會計算當前已執行的微代碼數量，達到一定閾值后就強制釋放GIL。而這時也會觸發一次操作系統的線程調度(當然是否真正進行上下文切換由操作系統自主決定)。

偽代碼

whileTrue:

acquireGIL

foriin1000:

dosomething

releaseGIL

/*GiveOperatingSystemachancetodothreadscheduling*/

這種模式在只有一個CPU核心的情況下毫無問題。任何一個線程被喚起時都能成功獲得到GIL(因為只有釋放了GIL才會引發線程調度)。但當CPU有多個核心的時候，問題就來了。從偽代碼可以看到，從releaseGIL到acquireGIL之間幾乎是沒有間隙的。所以當其他在其他核心上的線程被喚醒時，大部分情況下主線程已經又再一次獲取到GIL了。這個時候被喚醒執行的線程只能白白的浪費CPU時間，看著另一個線程拿著GIL歡快的執行著。然后達到切換時間后進入待調度狀態，再被喚醒，再等待，以此往復惡性循環。

PS：當然這種實現方式是原始而丑陋的，Python的每個版本中也在逐漸改進GIL和線程調度之間的互動關系。例如先嘗試持有GIL在做線程上下文切換，在IO等待時釋放GIL等嘗試。但是無法改變的是GIL的存在使得操作系統線程調度的這個本來就昂貴的操作變得更奢侈了。

關于GIL影響的擴展閱讀

為了直觀的理解GIL對于多線程帶來的性能影響，這里直接借用的一張測試結果圖(見下圖)。圖中表示的是兩個線程在雙核CPU上得執行情況。兩個線程均為CPU密集型運算線程。綠色部分表示該線程在運行，且在執行有用的計算，紅色部分為線程被調度喚醒，但是無法獲取GIL導致無法進行有效運算等待的時間。

GIL的存在導致多線程無法很好的立即多核CPU的并發處理能力。

那么Python的IO密集型線程能否從多線程中受益呢?我們來看下面這張測試結果。顏色代表的含義和上圖一致。白色部分表示IO線程處于等待。可見，當IO線程收到數據包引起終端切換后，仍然由于一個CPU密集型線程的存在，導致無法獲取GIL鎖，從而進行無盡的循環等待。

簡單的總結下就是：Python的多線程在多核CPU上，只對于IO密集型計算產生正面效果;而當有至少有一個CPU密集型線程存在，那么多線程效率會由于GIL而大幅下降

以上內容為大家介紹了python之當前GIL設計的缺陷，希望對大家有所幫助，如果想要了解更多Python相關知識，請關注IT培訓機構:千鋒教育。http://www.mycheba.com/