現(xiàn)在的Python有這么多方便優(yōu)秀的特性，可是有一個特性一直遲遲沒有實(shí)現(xiàn)：所有基于CPython的解釋器都不能同時(shí)在多個CPU核心上并行運(yùn)行啊app。
　　這一直是Python最大的絆腳石，特別是現(xiàn)有的實(shí)現(xiàn)方法都非常笨拙。目前，隨著現(xiàn)在處理器的核心數(shù)目不斷增長（英特爾最近發(fā)布了24核心的CPU），尋求一個長遠(yuǎn)的解決方案變得更加急不可待。
　　共用一個鎖
　　事實(shí)上，在Python中使用多線程是完全可以的——其實(shí)用的很多。但是對于CPython來說，不可能的事情是，在多個不同的CPU核心上并行運(yùn)行不同的線程。在CPython的內(nèi)存管理中存在安全隱患，所以解釋器每次只能運(yùn)行一個線程，然后根據(jù)需要控制鎖的全局狀態(tài)，在不同的線程中切換。
　　這種鎖的機(jī)制——解釋器全局鎖（the Global Interpreter Lock，GIL）是CPython不支持并行線程的根本原因。但是也有一些緩沖的中間件，比如，在硬盤上的IOS操作和網(wǎng)絡(luò)讀取不和GIL綁定，所以可以自由地并行運(yùn)行他們的線程，但是和CPU綁定的線程就成問題了。
　　對于Python程序員來說，這就意味著在大型計(jì)算任務(wù)方面的并行性能的損失。使用Python工作的方便伴隨著多線程性能方面的巨大損失，這時(shí)，同樣比較方便的其他語言就占了優(yōu)勢，比如Google的Go語言。
　　打破一個鎖
　　隨著時(shí)間的推移，人們相出了很多策略來優(yōu)化多線程——但大多都是治標(biāo)不治本——都沒有從根本上解決GIL的問題。一個標(biāo)準(zhǔn)的方案是，啟動多個CPython實(shí)例，然后在這些實(shí)例之間共享狀態(tài)和數(shù)據(jù)；每一個實(shí)例都獨(dú)立地運(yùn)行在不同的CPU上。但是Jeff Knupp說，這種方案帶來的收益會因?yàn)楣蚕頎顟B(tài)的成本大大損失。
　　C語言擴(kuò)展并不受GIL的限制，所以很多對速度要求很高的庫（比如科學(xué)計(jì)算庫Numpy）是用C實(shí)現(xiàn)的，可以多核多線程運(yùn)行。但是CPython的限制依然存在，如果說避免這個問題最好的方法是使用C擴(kuò)展的話，那么只會讓更多的程序員放棄Python而使用C語言。
　　PyPy，Python的自舉實(shí)現(xiàn)，采用了JIT技術(shù)，雖然沒有解決GIL的問題，但是大大提升了代碼運(yùn)行的速度。從某種方面講，如果只看速度的話，也差不到哪里去，但是從根本上講，并沒有解決多線程的問題。
　　最后，GIL在Python 3中得到了優(yōu)化，有了更好的線程切換。但是根本問題依然存在——由于GIL程序還是不能真正地多線程并行運(yùn)行。
　　沒有GIL？沒有問題
　　拋開上面這些問題不說，對沒有GIL的、兼容現(xiàn)有app的Python的追求從未停止。很多Python的其他實(shí)現(xiàn)都完全原離GIL，但是都遭到了性能上的損失。比如，一個運(yùn)行在JVM之上的Python實(shí)現(xiàn)——Jython，使用了JVM的對象跟蹤系統(tǒng)，而不是GIL。IronPython采用了和微軟的CLR相同的策略。但是兩者的性能都很反常。有時(shí)候，它們表現(xiàn)的比CPython還慢，有時(shí)候不兼容外部的C代碼，所以很多程序并不能正常工作。
　　Trent Nelson of Continuum Analytics的一個叫PyParallel的項(xiàng)目，是一個“實(shí)驗(yàn)性的，理論證明可行的對多核心CPU并行運(yùn)算優(yōu)化的Python 3設(shè)計(jì)實(shí)現(xiàn)。”它并沒有廢棄GIL，但是通過替換async優(yōu)化了它的引入，所以應(yīng)用可以使用async來并行運(yùn)算（就像IO、網(wǎng)絡(luò)服務(wù)器一樣）。這個項(xiàng)目已經(jīng)停滯好幾個月了，但是從文檔來看，它的開發(fā)者對這樣的進(jìn)度很滿意。最終，他們在CPython中這樣宣布：“慢點(diǎn)沒什么，只要方向?qū)α司涂梢浴！?br /> 　　PyPy的創(chuàng)始人有一個長期的項(xiàng)目，這個Python的實(shí)現(xiàn)使用了一種叫“軟件內(nèi)存交換（software transactional memory）”（PyPy-STM）的技術(shù)。根據(jù)PyPy創(chuàng)始人的說法，好處是，“這個項(xiàng)目可以對現(xiàn)有的程序優(yōu)化，使沒有多線程運(yùn)行的程序可以在多個核心上運(yùn)行。”
　　PyPy-STM聽起來像魔法一樣，但是它有兩個缺點(diǎn)。第一，現(xiàn)在這個項(xiàng)目還在開發(fā)中，目前只支持2.X。第二，對于單線程的程序，性能有所下降。根據(jù)Python的創(chuàng)始人范·羅蘇姆規(guī)定的條款，任何有關(guān)解決GIL的嘗試，都不能降低單線程程序運(yùn)行的速度。所以，這個項(xiàng)目暫時(shí)不能被CPython接受。
　　進(jìn)步與等待
　　Python的核心開發(fā)者Larry Hastings在PyCon 2016上分享了一些關(guān)于解決GIL問題的觀點(diǎn)，Hastings分享了他關(guān)于GIL問題的嘗試，并在最后給出了一個沒有GIL的Python實(shí)現(xiàn)，但是因?yàn)榫彺鎲栴}，性能也不盡人意。
　　Hastings在最后總結(jié)到，你可以刪掉GIL，但是你必須有一種方法來確保每次只有一個線程在操作全局對象——比如，使用一個公有線程，讓解釋器來處理狀態(tài)的改變。
　　一個好消息是，如果CPython修復(fù)了GI了的問題，那么開發(fā)者使用Python可以輕松地開發(fā)多線程程序。因?yàn)镻ython的語法在不斷優(yōu)化，Python 3.5以來，async/await語法使得開發(fā)多線程程序非常簡單。
　　現(xiàn)在，關(guān)于Python GIL的問題還有很多工作需要做。但是毫無疑問的是，問題的第一個答案將是像PyPy-STM一樣的單獨(dú)的Python實(shí)現(xiàn)。現(xiàn)在如果想嘗試一下沒有GIL的Python，可以試一下第三方的版本。CPython目前沒有任何反應(yīng)，期待等待的時(shí)間不會太長。
?