GIL這么爛，有沒(méi)有辦法繞過(guò)呢?我們來(lái)看看有哪些現(xiàn)成的python方案。

用multiprocess替代Thread

multiprocess庫(kù)的出現(xiàn)很大程度上是為了彌補(bǔ)thread庫(kù)因?yàn)镚IL而低效的缺陷。它完整的復(fù)制了一套thread所提供的接口方便遷移。唯一的不同就是它使用了多進(jìn)程而不是多線程。每個(gè)進(jìn)程有自己的獨(dú)立的GIL，因此也不會(huì)出現(xiàn)進(jìn)程之間的GIL爭(zhēng)搶。

當(dāng)然multiprocess也不是萬(wàn)能良藥。它的引入會(huì)增加程序?qū)崿F(xiàn)時(shí)線程間數(shù)據(jù)通訊和同步的困難。就拿計(jì)數(shù)器來(lái)舉例子，如果我們要多個(gè)線程累加同一個(gè)變量，對(duì)于thread來(lái)說(shuō)，申明一個(gè)global變量，用thread.Lock的context包裹住三行就搞定了。而multiprocess由于進(jìn)程之間無(wú)法看到對(duì)方的數(shù)據(jù)，只能通過(guò)在主線程申明一個(gè)Queue，put再get或者用sharememory的方法。這個(gè)額外的實(shí)現(xiàn)成本使得本來(lái)就非常痛苦的多線程程序編碼，變得更加痛苦了。

用其他解析器

之前也提到了既然GIL只是CPython的產(chǎn)物，那么其他解析器是不是更好呢?沒(méi)錯(cuò)，像JPython和IronPython這樣的解析器由于實(shí)現(xiàn)語(yǔ)言的特性，他們不需要GIL的幫助。然而由于用了Java/C#用于解析器實(shí)現(xiàn)，他們也失去了利用社區(qū)眾多C語(yǔ)言模塊有用特性的機(jī)會(huì)。所以這些解析器也因此一直都比較小眾。畢竟功能和性能大家在初期都會(huì)選擇前者，Doneisbetterthanperfect。

所以沒(méi)救了么?

當(dāng)然Python社區(qū)也在非常努力的不斷改進(jìn)GIL，甚至是嘗試去除GIL。并在各個(gè)小版本中有了不少的進(jìn)步。有興趣的讀者可以擴(kuò)展閱讀這個(gè)Slide

另一個(gè)改進(jìn)ReworkingtheGIL

–將切換顆粒度從基于opcode計(jì)數(shù)改成基于時(shí)間片計(jì)數(shù)

–避免最近一次釋放GIL鎖的線程再次被立即調(diào)度

–新增線程優(yōu)先級(jí)功能(高優(yōu)先級(jí)線程可以迫使其他線程釋放所持有的GIL鎖)

以上內(nèi)容為大家介紹了Python之如何避免受到GIL的影響，希望對(duì)大家有所幫助，如果想要了解更多Python相關(guān)知識(shí)，請(qǐng)關(guān)注IT培訓(xùn)機(jī)構(gòu):千鋒教育。http://www.parentadvocate.org/