python为什么不解除gil_为什么 Python 的 GIL 问题一直让人诟病，Python 社区却不解决？...

一是部分诟病的人所碰到的性能问题，真正原因并不是 GIL。他们不知道，或者知道但只需要一个可以甩锅的点。这些人不会正确 benchmark 也不了解实现，自然没有能力去改。另一部分批评的人是为了推广自家语言或者彰显优越感，这些人没有动力去改。

二是改起来太费劲。参考 Java 的实现，虚拟机里要管理很多细粒度的锁才能保证正确性，改得不好单线程的性能要大打折扣。有能力改的人要么认为这根本不需要改，要么没精力改。Yes, PyPy has a GIL. Removing the GIL is very hard. On top of CPython, you have two problems: (1) GC, in this case reference counting; (2) the whole Python language.

For PyPy, the hard issue is (2): by that I mean issues like what occurs if a mutable object is changed from one thread and read from another concurrently. This is a problem for any mutable type: it needs careful review and fixes (fine-grained locks, mostly) through the whole Python interpreter. It is a major effort, although not completely impossible, as Jython/IronPython showed. This includes subtle decisions about whether some effects are ok or not for the user (i.e. the Python programmer).

CPython has additionally the problem (1) of reference counting. With PyPy, this sub-problem is simpler: we need to make our GC multithread-aware. This is easier to do efficiently in PyPy than in CPython. It doesn’t solve the issue (2), though.

Note that since 2012 there is work going on on a still very experimental Software Transactional Memory (STM) version of PyPy. This should give an alternative PyPy which works without a GIL, while at the same time continuing to give the Python programmer the complete illusion of having one. This work is currently a bit stalled because of its own technical difficulties.

有一个捷径是用软件事务内存，保留 GIL 的代码，但如果没有同时写同一块内存就不是真的锁定。

x86 也有 TSX 扩展，但这些尝试能否实用到 x86 的处理器就很难说了。

好了就算你用 HTM 减少了锁的工作量，还有大量语言设计上的问题，这些矛盾和取舍不是几个人发篇文章就能搞得定的。