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

用multiprocess替代Thread

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

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

用其他解析器

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

所以沒救了么?

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

另一個改進(jìn)ReworkingtheGIL

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

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

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

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