为什么Python中的多线程速度较慢？
为什么Python中的多线程速度慢？
Python的全局解释器锁（GIL）的设计初衷是为了序列化来自不同线程的对解释器内部的访问。在多核系统上，这意味着多个线程无法有效地利用多个核心。（如果GIL没有导致这个问题，大多数人都不会关心GIL——只有因为多核系统日益普及，才会成为一个问题。）如果你想详细了解，你可以观看这个视频或查看这组幻灯片。可能会有太多的信息，但你确实要求了详细信息。
请注意，Python的GIL只对CPython这个参考实现真正的是一个问题。Jython和IronPython没有GIL。作为Python开发者，你通常不会遇到GIL，除非你在编写C扩展。C扩展的编写者需要在其扩展进行阻塞I/O时释放GIL，以便Python进程中的其他线程有机会运行。
好答案-基本上意味着Python中的线程只适用于阻塞I/O；你的应用程序永远不会超过1个CPU核心的处理器使用率。
“作为Python开发者，你通常不会遇到GIL，除非你在编写C扩展”-你可能不知道你的多线程代码运行缓慢的原因是GIL，但你肯定会感受到它的影响。让我仍然感到惊讶的是，要利用32核服务器的Python，我需要32个进程以及所有相关的开销。
不准确。性能关键代码很可能已经使用了可以释放GIL的C扩展，例如正则表达式、lxml和numpy模块。Cython允许在自定义代码中释放GIL，例如b2a_bin(data)。
Betts：你可以使用multiprocessing模块获得超过1个CPU核心的处理器使用率。创建多个进程比创建多个线程更“重”，但如果你真的需要并行处理工作，在Python中这是一个选择。
很棒，从你的幻灯片链接中，我刚刚了解到了checkinterval（导致我的线程冲突）。有趣的是，在编写改变共享数据的多线程解决方案时，我们必须小心。以前不知道这一点，以为GIL和操作系统的时间切片会处理一切。
很棒的视频，非常好的演示。它展示了GIL有多么混乱。还有一个关于GIL的很好的视频是在PyCon 2017上做的。
对于Python3来说，情况还是这样吗？这个问题会改变吗？
_adler是的，情况仍然如此，并且在可预见的未来可能仍然如此。这并没有真正阻止Python在许多不同的工作负载上非常有用。