Java GC 线程瓶颈在实践中？
Java 的并行收集 GC 对于多线程环境的优化程度如何？我编写了一些多线程 Jython 代码，这些代码大部分时间都在调用 Java 库。根据我运行程序的选项，库调用要么在幕后进行大量分配，要么几乎不进行分配。当我使用需要大量堆分配的选项时，我无法让代码扩展到超过 6 个核心。当我使用不需要大量分配的选项时，它会扩展到至少 20。鉴于我使用的是库存 Sun VM、并行 GC 和 Jython，这与 GC 瓶颈相关的可能性有多大作为我的粘合语言？
编辑：澄清一下，我不一定会想到对 Java 老手来说显而易见的东西，因为我几乎从不使用 Java/JVM 语言。我的大部分编程都是用 D 和 Python 的旗舰 CPython 实现完成的。我正在将 JVM 和 Jython 用于一个小型一次性项目，因为我需要访问 Java 库。
How well optimized is Java's parallel collecting GC for multithreaded environments? I've written some multithreaded Jython code that spends most of its time calling Java libraries. Depending on which options I run the program with, the library calls either do tons of allocations under the hood or virtually none. When I use the options that require tons of heap allocations, I can't get the code to scale past 6 cores. When I use the options that don't require lots of allocations, it scales to at least 20. How likely is it that this is related to a GC bottleneck, given that I'm using the stock Sun VM, the parallel GC and Jython as my glue language?
Edit: Just to clarify, I won't necessarily think of stuff that's obvious to Java veterans because I almost never use Java/JVM languages. I do most of my programming in D and the flagship CPython implementation of Python. I'm using the JVM and Jython for a small one-off project b/c I need access to a Java library.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
由于您的问题是关于 GC 瓶颈：您可以通过打开 GC 日志记录并检查日志来消除这种可能性 - 如果存在大量暂停时间较长的 GC 事件，您可以确认/否定这个理论。 （但是，在您描述的场景中，我猜这不是 GC 问题）。
Since your question is about GC bottlenecks: you can eliminate that possibility by turning on GC logging and checking the logs - if there are large number of GC events with large pauses you can confirm/discount this theory. (However, in the scenario you describe, i would guess it is not a GC issue).
对我来说，GC 和多线程的问题是非常现实的。我并不是说 JVM 不好，只是问题本身很难处理。
在我们的一个项目中，我们有两个应用程序在单个 JVM（应用程序服务器）中运行。当单独对它们施加压力时，这很好，但当两者一起承受压力时，性能会以奇怪的方式下降。我们最终拆分了应用程序。在两个 JVM 中，性能恢复正常（当然比仅使用一个应用程序时慢，但合理）。
调整 GC 非常困难。情况可能会改善 5 分钟，然后主要集合将阻塞，等等。您可能会决定操作中是否需要高吞吐量或低延迟。高吞吐量适合批处理，低延迟则适合交互式应用程序。最终，JVM 的默认参数对我们来说是给出最佳结果的参数！
这并不是真正的答案，而是经验的回报，但是，是的，对我来说 GC 和多线程可能是一个问题。
To me, problems with GC and multithreading are very real. I'm not saying the JVM is bad, it's just that the problem itself is very hard to deal with.
In one of our project, we had two applications running in a single JVM (app. server). When stressing them individually that was fine, but when both were stress together performance degraded in strange way. We finally split the apps. in two JVMs, and performance went back to normal (of course slower than when only one app was use, but reasonable).
Tuning the GC is extremely hard. Things can improve for 5 minutes, and then a major collection will block, etc. You might decide whether you want high throughput or low latency in the operations. High throughput is fine for batch processing, low latency is necessary for interactive application. Ultimately, the default parameters of the JVM were for us the one giving the best results!
That's not really an answer, rather a return on experience, but yes, to me GC and multi threading might be an issue.
Java GC 是分代的。第一代集合旨在处理短命对象，并预计会频繁运行。如果存在许多短期分配，那么每秒运行几次短时间间隔是预期的行为。 （这应该是评论而不是答案 - 我没有代表，抱歉）。
此外，根据您使用的虚拟机，您可以选择 GC 算法。这些选项将根据您使用的 VM 的版本和供应商而有所不同。
一些（旧）信息在这里： http://java.sun.com /developer/technicalArticles/Programming/turbo/#The_new_GC
The Java GC is generational. A collection of first generation is meant to take care of short-lived objects and is expected to run frequently. Running for a short interval several times per second is the expected behaviour if there are many short-lived allocations. (This should be a comment rather than an answer - I have no rep, sorry).
Also, depending on which VM you are using, you can choose between GC algorithms. The options will vary depending on which version and vendor of the VM you are using.
Some (old) info is here: http://java.sun.com/developer/technicalArticles/Programming/turbo/#The_new_GC
线程性能因 jdk 版本而异。根据我的经验，在 jdk6u18 上，使用 -XX:+UseParallelGC（不是并发标记扫描 gc）启用的并行 gc 在具有数百个非常活跃的线程的四核上表现得非常好。我认为它不太可能扩展到超过 6 个核心。
事实上，Sun 的硬件基于具有大量内核的处理器，这解释了为什么他们近年来在新的垃圾收集器上投入了大量精力。
并行GC默认是不启用的，因为它的单线程性能不如默认的GC。
Threading performance can vary from one jdk version to another. In my experience, on jdk6u18, the parallel gc, enabled with -XX:+UseParallelGC (not the concurrent mark sweep gc), performs very well on a quad core with hundreds of very active threads. I consider it very unlikely that it would not scale beyond 6 cores.
The fact that Sun's hardware is based on processors with a high number of cores explains why they've put a lot of effort in new garbage collectors in recent years.
The parallel gc is not enabled by default because its single threaded performance is not as good as the default gc.