java 为什么Java虚拟机中没有GIL？为什么 Python 需要这么差？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/991904/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why is there no GIL in the Java Virtual Machine? Why does Python need one so bad?
提问by AgentLiquid
I'm hoping someone can provide some insight as to what's fundamentally different about the Java Virtual Machine that allows it to implement threads nicely without the need for a Global Interpreter Lock (GIL), while Python necessitates such an evil.
我希望有人能提供一些关于 Java 虚拟机的根本不同之处的见解，它允许它在不需要全局解释器锁 (GIL) 的情况下很好地实现线程，而 Python 需要这样的邪恶。
回答by Alex Martelli
Python (the language) doesn't need a GIL (which is why it can perfectly be implemented on JVM [Jython] and .NET [IronPython], and those implementations multithread freely). CPython (the popular implementation) has always used a GIL for ease of coding (esp. the coding of the garbage collection mechanisms) and of integration of non-thread-safe C-coded libraries (there used to be a ton of those around;-).
Python（语言）不需要 GIL（这就是为什么它可以在 JVM [Jython] 和 .NET [IronPython] 上完美实现，并且这些实现是多线程自由的）。CPython（流行的实现）一直使用 GIL 来简化编码（尤其是垃圾收集机制的编码）和非线程安全的 C 编码库的集成（曾经有很多这样的库； -)。
The Unladen Swallowproject, among other ambitious goals, does plana GIL-free virtual machine for Python -- to quote that site, "In addition, we intend to remove the GIL and fix the state of multithreading in Python. We believe this is possible through the implementation of a more sophisticated GC system, something like IBM's Recycler (Bacon et al, 2001)."
该空载燕子项目，其它的宏伟目标中，做计划一个GIL -免费的虚拟机为Python -引用该网站，“此外，我们打算移除GIL和修复在Python多线程的状态，我们认为，这是通过实施更复杂的 GC 系统，例如 IBM 的 Recycler（Bacon 等人，2001），可以实现这一目标。”
回答by Greg Bowyer
The JVM (at least hotspot) does have a similar concept to the "GIL", it's just much finer in its lock granularity, most of this comes from the GC's in hotspot which are more advanced.
JVM（至少是热点）确实有一个类似于“GIL”的概念，它的锁粒度更细，其中大部分来自更先进的热点中的GC。
In CPython it's one big lock (probably not that true, but good enough for arguments sake), in the JVM it's more spread about with different concepts depending on where it is used.
在 CPython 中，它是一个大锁（可能不是那么正确，但对于争论来说已经足够了），在 JVM 中，根据使用它的位置，它更多地散布着不同的概念。
Take a look at, for example, vm/runtime/safepoint.hpp in the hotspot code, which is effectively a barrier. Once at a safepoint the entire VM has stopped with regard to java code, much like the python VM stops at the GIL.
例如，查看热点代码中的 vm/runtime/safepoint.hpp，这实际上是一个屏障。一旦到达安全点，整个虚拟机就 Java 代码停止，就像 Python 虚拟机停止在 GIL 一样。
In the Java world such VM pausing events are known as "stop-the-world", at these points only native code that is bound to certain criteria is free running, the rest of the VM has been stopped.
在 Java 世界中，此类 VM 暂停事件被称为“stop-the-world”，此时只有绑定到特定条件的本机代码可以自由运行，VM 的其余部分已停止。
Also the lack of a coarse lock in java makes JNI much more difficult to write, as the JVM makes less guarantees about its environment for FFI calls, one of the things that cpython makes fairly easy (although not as easy as using ctypes).
此外，java 中缺少粗锁使得 JNI 更难编写，因为 JVM 对其 FFI 调用的环境的保证较少，cpython 使之相当容易的事情之一（尽管不如使用 ctypes 容易）。
回答by user235859
There is a comment down below in this blog post http://www.grouplens.org/node/244that hints at the reason why it was so easy dispense with a GIL for IronPython or Jython, it is that CPython uses reference counting whereas the other 2 VMs have garbage collectors.
在这篇博文http://www.grouplens.org/node/244下面有一条评论，暗示了为什么为 IronPython 或 Jython 免除 GIL 如此容易的原因，是 CPython 使用引用计数，而其他 2 个 VM 有垃圾收集器。
The exact mechanics of why this is so I don't get, but it does sounds like a plausible reason.
我不明白为什么会这样的确切机制，但这听起来确实是一个合理的原因。
回答by Oliver Wilken
In this linkthey have the following explanation:
在此链接中，他们有以下解释：
... "Parts of the Interpreter aren't threadsafe, though mostly because making them all threadsafe by massive lock usage would slow single-threaded extremely (source). This seems to be related to the CPython garbage collector using reference counting (the JVM and CLR don't, and therefore don't need to lock/release a reference count every time). But even if someone thought of an acceptable solution and implemented it, third party libraries would still have the same problems."
...“解释器的一部分不是线程安全的，尽管主要是因为通过大量锁使用使它们全部线程安全会极大地减慢单线程（来源）。这似乎与使用引用计数的 CPython 垃圾收集器（JVM而 CLR 没有，因此不需要每次都锁定/释放引用计数。但即使有人想到了一个可接受的解决方案并实施了它，第三方库仍然会遇到同样的问题。”
回答by Jim
Python lacks jit/aot and the time frame it was written at multithreaded processors didn't exist. Alternatively you could recompile everything in Julia lang which lacks GIL and gain some speed boost on your Python code. Also Jython kind of sucks it's slower than Cpython and Java. If you want to stick to Python consider using parallel plugins, you won't gain an instant speed boost but you can do parallel programming with the right plugin.
Python 缺少 jit/aot 并且它在多线程处理器上编写的时间框架不存在。或者，您可以在缺少 GIL 的 Julia lang 中重新编译所有内容，并在您的 Python 代码上获得一些速度提升。Jython 也有点糟糕，它比 Cpython 和 Java 慢。如果您想坚持使用 Python，请考虑使用并行插件，您不会立即获得速度提升，但您可以使用正确的插件进行并行编程。
