javagc线程在实践中的瓶颈?

对我来说,GC和多线程的问题是非常现实的。我不是说JVM不好,只是这个问题本身很难处理。

在我们的一个项目中,我们在一个JVM(app)中运行了两个应用程序。服务器)。当他们单独承受压力时,这是好的,但当两者同时承受压力时,表现会以奇怪的方式退化。我们终于把这些应用分开了。在两个jvm中,性能恢复正常(当然比只使用一个应用程序时慢,但合理)。

调整GC是非常困难的。事情可以改善5分钟,然后一个主要的收集将阻塞,等等。您可以决定在操作中是要高吞吐量还是低延迟。高吞吐量适合于批处理,低延迟对于交互式应用程序是必需的。最终,JVM的默认参数对我们来说是给出最佳结果的参数!

可以 这是个问题。

因为您的问题是关于GC瓶颈的:您可以通过打开GC日志并检查日志来消除这种可能性-如果有大量GC事件具有大的暂停,您可以确认/否认这个理论(但是,在您描述的场景中,我猜这不是GC问题)。

javagc是分代的。第一代的集合是用来处理短命对象的,并且期望经常运行。如果存在许多短期分配,则每秒运行几次短时间间隔是预期的行为(这应该是一个评论,而不是一个答案-我没有代表,对不起)。

以下是一些(旧)信息: http://java.sun.com/developer/technicalArticles/Programming/turbo/#The_new_GC

线程性能因jdk版本而异。根据我的经验,在jdk6u18上,并行gc使用-XX:+usepallelgc启用( 不

Sun的硬件基于具有大量内核的处理器这一事实解释了为什么近年来他们在新的垃圾收集器上投入了大量精力。

默认情况下不启用并行gc,因为它的单线程性能不如默认gc。