今天看了一篇文章Python 最难的问题，说到Python受限于GIL。不要使用多线程，请使用多进程。
问：
- Python多核利用的问题，在以后会解决吗？
- 其他解释型语言，如Ruby是不是也存在同样的问题？
- 目前的解决方案是什么？
回复内容：
Ruby也有GIL，其实GIL并不是性能问题的根源，性能问题的根源是GC。
假设去掉GIL，像Java那样的多核多线程，你会面临更多头疼的OOM问题，以及GC问题，Java的一次Full GC是stop whole world的，你不希望你整个服务器8颗内核一起stop，等待GC完成吧？
所以Java这么多年疯狂投入努力改进VM的GC效率，搞出来各种GC算法，特别是并行GC算法。而且在大内存服务器上，为了提高GC效率，避免过大的内存堆扫描开销，Java现在也强调单机跑多进程呢。
所以你认为Python/Ruby去掉GIL，就解决问题了吗？事实上会引入更多更麻烦的问题。
如果为了提高IO并发性能，用协程就同样可以达到目的，Ruby现在原生支持协程，Lua则是协程方面效率极高的脚本语言，已经证明了这条路。
最后说到多核的问题，Ruby未来发展方向是MVM，即单进程里面跑多个VM，每个CPU内核跑一个VM，每个VM有自己的GC。这个办法其实很不错，既有效利用了进程共享内存，又可以支持多核并行，还解决了全局GC的性能问题。
- 在可以遇见的相当长一段时间内，Python 的官方实现 CPython 不会解决 GIL 的问题。
- Ruby 的官方实现 MRI 也有这个问题。
- 解决方案有很多，最常见的当然是用多进程。如果条件允许，也可以选择没有 GIL 限制的实现，比如基于 JVM 的 Jython 和 JRuby。
Python当然可以利用多核。
关于Python最大的误区大概就是“Python的多线程不能利用多核”会传来传去以后变成“Python不能利用多核”。
以现在Python主流应用之一服务器开发举例，根据CPU核心开对应数量的进程是非常普遍的做法。
至于非要用“多线程”的场合（比如异步），也有不少“协程”方案可以使用，比如stackless python，又比如greenlet，以及由此发展出的可爱的gevent。首先，语言应该在什么级别支持多线程。C 通过操作系统的 preemptive scheduler 支持多线程，同时提供 critical section, wait/notify 这样的同步机制。问题在于，这样的同步机制太低级，在实际应用中经常需要封装为高级的同步机制，比如多线程的生产者－消费者队列。高级动态语言的设计者面临三个选择：
- 在语言中直接提供类似 C 的机制（Java）；
- 设计良好的 C 接口，在同一进程中运行多个虚拟机，利用 C 把低级同步机制封装成多虚拟机之间的高本文来源gaodai.ma#com搞##代!^码7网
级同步机制（Lua），或者把多线程优化完全封装在一个 API 之内（比如 Intel MKL 的各种多核算法）。
- 多进程。
方法 1 是得不偿失的。因为低级同步机制的优势在于效率，而考虑效率就必须考虑诸如 L1/L2/L3 cache 实效之类的底层情况。这对于解释执行的语言（即使有 JIT）来说是无法控制的。所以高级动态语言提供底层同步机制实际没有必要。应该多走方法 2 和 3。其中又以 2 最为灵活。
移除 GIL 难吗？不难，因为根本没有必要移除。如果 Python 能在一个进程中初始化多个 VM，同时其标准库在 C 级别做出足够多的常用多核优化就没有问题。Python 其实是希望实现另一个功能，异步操作。尽管异步操作和并行计算都可以通过多线程来完成，但是其实前者更加适合用协程或者用户级线程来完成。但是 Python 是 stackful 实现，也就是 byte code 借用 C runtime stack 来维护自己的运行状态。这种机制的弱点就是不容易用跨平台的方式来实现协程，所以利用 OS 多线程加 GIL 也就成了模拟协程语意的妥协手段。
补充一下。C 的线程和线程同步机制虽然底层，但是只有这种机制才能覆盖所有 use case。而其它的高层抽象只能适合某种 case。所以，当我说高级动态语言需要高级的线程操作时，我的隐含意思是这种语言同时还要有和 C 进行良好的互操作来随时扩展这种抽象。
转载请注明原文链接：Python 不能利用多核的问题以后能被解决吗？
