其他编程语言/平台对垃圾收集器(如JVM )有问题吗？

Question

我只想知道其他编程语言/平台，如PHP，Ruby，C#等(在这里你不必手动处理内存管理)是否有像Java on JVM这样的GC同样的问题，导致大堆(> 5 5gb)上的长暂停，高响应时间，低吞吐量等？

或者这是所有具有GC能力的语言/平台的普遍问题，但它在Java世界中是一个热门的讨论主题，仅仅因为有许多大型系统是用Java编写的，而且更多的人必须在其他地方处理这个问题？

非常感谢！

Answer 1

是的，所有基于GC的语言对于非常大的堆都会有类似的问题。它与语言几乎没有关系，而与VM实现(当然还有GC调优选项和应用程序代码)有很大关系。由于具有非常大的堆的应用程序仍然很少，但变得越来越普遍，这正在成为替代VM实现的供应商的主要卖点，例如IBM或Azul Systems。

Answer 2

对于.NET来说，不是。垃圾收集是自动发生的，在大多数情况下，您不需要担心垃圾收集，因为托管堆会被持续监视，并根据需要执行收集。

但是，如果您确实需要对垃圾收集进行一些控制，则可以使用control the latency mode并使用measure of control over inducing collection。

在一个相关的主题中，即使在托管代码中，您仍然可能存在内存泄漏。如果是这样的话，垃圾收集器触发的频率或效率都无关紧要了……

Answer 3

这与编程语言无关。这是一个垃圾收集器实现的质量问题。

自20世纪70年代以来，具有可预测和可调暂停时间的实时垃圾收集器已为人所知。现在，它变得更容易了:因为机器通常有1000个CPU，所以只需留出几十个左右的CPU供垃圾收集器运行，并并发执行收集。

例如，Azul Jaca Compute Appliance就是这样做的。它是专门为具有非常大的堆和接近实时需求的非常大的应用程序而设计的(例如，用于对冲的自动化交易系统)。由于JCA运行的是JVM，并且Ruby和PHP (以及Python、Smalltalk、Lisp、Scheme、JAvaScript、…)在JVM上运行，它们也可以访问该技术。

当前版本(JCA7300)具有高达864个CPU和768 GiByte的内存。通常，leaving收集器将使用20-30个CPU，剩下的700个( JIT编译器也使用12个或3个)用于应用程序。这仍然远远超出了几乎所有应用程序的处理能力。