像JVM这样的垃圾收集器有其他编程语言/平台问题吗？

Question

我只是想知道其他编程语言/平台，如PHP，Ruby，C＃等（你不必手动处理内存管理）与JVM上的Java相同的问题，导致长时间暂停，大堆大小（> 5gb）的高响应时间，低吞吐量等？

或者这是所有具有GC-Ability的语言/平台的普遍问题，但它在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，只需设置几十个左右就可以运行垃圾收集器，并同时进行收集。

例如，Azul Jaca Compute Appliance就是这样做的。它专为具有非常大的堆和近实时要求的非常大的应用程序而设计（例如，用于hedgefonds的自动交易系统）。由于JCA运行JVM，并且在JVM上运行Ruby和PHP（以及Python，Smalltalk，Lisp，Scheme，JAvaScript等），因此他们也可以访问该技术。

当前版本（JCA 7300）具有多达864个CPU和768 GiByte RAM。通常，垃圾收集器将使用20-30个CPU，远远超过700个（JIT编译器也使用十几个或者三个）用于应用程序。这仍然比几乎所有应用程序都能处理的更多。