我只是想知道是否其他编程语言/平台，如PHP, Ruby, c#等(在那里你不需要手动处理内存管理)有GC像Java在JVM上导致长暂停，高响应时间，低吞吐量等大堆大小(> 5gb)相同的问题?
或者这是所有具有GC-Ability的语言/平台的普遍问题，但它在Java世界中是一个热门的讨论主题，只是因为有许多大型系统是用Java编写的，而且人们经常不得不处理这个问题，而不是其他地方?
非常感谢!
是的，所有基于gc的语言对于非常大的堆都会有类似的问题。它与语言几乎没有关系，而是与VM实现(以及GC调优选项，当然还有应用程序代码)有关。由于使用非常大的堆的应用程序仍然非常罕见，但正变得越来越普遍，这正在成为替代VM实现供应商(如IBM或Azul Systems)的主要卖点。
对于。net来说，没有。垃圾收集是自动发生的，在大多数情况下，您不需要担心这一点，因为托管堆是持续监控的，收集是根据需要执行的。
但是，如果您确实需要对垃圾收集进行一些控制，则可以控制延迟模式并对诱导收集进行一定程度的控制。
在一个相关的主题上，你仍然可以有内存泄漏，即使在托管代码中。如果是这种情况，那么垃圾收集器触发的频率和效率都无关紧要。这与编程语言无关。这是垃圾收集器实现质量的问题。
自20世纪70年代以来，具有可预测和可调暂停时间的实时垃圾收集器已经为人所知。现在，它变得更容易了:由于机器通常有1000个cpu，只需留出几十个左右的cpu供垃圾收集器运行，并并发地进行收集。 例如，Azul Jaca Compute Appliance就是这样做的。它专门为具有非常大的堆和近实时需求的非常大的应用程序(例如对冲基金的自动交易系统)而设计。由于JCA运行JVM，并且Ruby和PHP(以及Python、Smalltalk、Lisp、Scheme、JAvaScript等)都运行在JVM上，因此它们也可以访问该技术。当前版本(JCA 7300)有多达864个cpu和768吉字节的RAM。通常，垃圾收集器将使用20 - 30个cpu，为应用程序留下700多个cpu (JIT编译器也使用十几个或三个cpu)。这仍然远远超出了几乎所有应用程序的处理能力。