为什么Java虚拟机中没有GIL？ 为什么 Python 这么需要一个？
我希望有人能够提供一些关于 Java 虚拟机的根本不同之处的见解，它允许它很好地实现线程，而不需要全局解释器锁（GIL），而 Python 则需要这样的邪恶。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Python（语言）不需要 GIL（这就是为什么它可以在 JVM [Jython] 和 .NET [IronPython] 上完美实现，并且这些实现可以自由地进行多线程）。 CPython（流行的实现）始终使用 GIL 来简化编码（尤其是垃圾收集机制的编码）和非线程安全 C 编码库的集成（以前有很多这样的库； -)。
除其他雄心勃勃的目标外，Unladen Swallow 项目还实现了计划一个用于 Python 的无 GIL 虚拟机 —— 引用该网站的话，“此外，我们打算删除 GIL 并修复 Python 中的多线程状态，我们相信通过实施更复杂的 GC 系统（例如 IBM 的 Recycler）（Bacon 等人，2001 年）是可能的。”
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;-).
The Unladen Swallow project, among other ambitious goals, does plan a 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)."
JVM（至少是热点）确实与“GIL”有类似的概念，只是锁粒度更细，其中大部分来自更先进的热点中的GC。
在 CPython 中，它是一把大锁（可能不是那么正确，但对于争论而言已经足够好了），在 JVM 中，它根据使用位置的不同，以不同的概念传播得更多。
例如，看看热点代码中的 vm/runtime/safepoint.hpp，它实际上是一个障碍。 一旦到达安全点，整个虚拟机就会停止处理 java 代码，就像 python 虚拟机在 GIL 处停止一样。
在 Java 世界中，此类 VM 暂停事件被称为“stop-the-world”，此时只有受某些标准约束的本机代码可以自由运行，VM 的其余部分已停止。
此外，java 中缺乏粗略锁使得 JNI 的编写更加困难，因为 JVM 对 FFI 调用的环境的保证较少，而 cpython 使之变得相当容易（尽管不像使用 ctypes 那么容易）。
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.
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.
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.
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.
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).
这篇博文下面有一条评论 http://www.grouplens.org/node/244 这暗示了为什么 IronPython 或 Jython 如此容易省去 GIL 的原因是 CPython 使用引用计数，而其他 2 个 VM 有垃圾收集器。
我不明白为什么会这样的确切机制，但听起来确实是一个合理的原因。
There is a comment down below in this blog post http://www.grouplens.org/node/244 that 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.
The exact mechanics of why this is so I don't get, but it does sounds like a plausible reason.
在此链接 他们有以下解释：
...“解释器的某些部分不是线程安全的，尽管主要是因为通过大量使用锁使它们全部线程安全会极大地减慢单线程速度（源）。这似乎与使用的 CPython 垃圾收集器有关引用计数（JVM 和 CLR 没有，因此不需要每次都锁定/释放引用计数），但即使有人想到了可接受的解决方案并实现了它，第三方库仍然会遇到相同的问题。 ”。
In this link they 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."
Python 缺乏 jit/aot 并且它在多线程处理器上编写的时间框架不存在。 或者，您可以在 Julia lang 中重新编译缺少 GIL 的所有内容，并提高 Python 代码的速度。 Jython 也有点糟糕，它比 Cpython 和 Java 慢。 如果你想坚持使用Python，请考虑使用并行插件，你不会立即获得速度提升，但你可以使用正确的插件进行并行编程。
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.