java8默认垃圾收集器 - java:+ useg1gc




生产中的Java G1垃圾收集 (11)

Azul的首席技术官Gil Tene对垃圾收集相关问题进行了很好的概述,并在他的“ 了解Java垃圾收集和你能做些什么”演示文稿中回顾了各种解决方案,本文还提供了其他细节: http://www.infoq.com/articles/azul_gc_in_detail

我们的Zing JVM中的Azul C4垃圾收集器既是并行的又是并行的,并且对于新老两代都使用相同的GC机制,在这两种情况下同时工作和压缩。 最重要的是,C4没有停止世界的倒退。 所有压缩与正在运行的应用程序同时执行。 我们的客户运行时间非常长(数百GB),并且GC暂停时间<10毫秒的情况更糟,并且视应用程序而定,通常时间少于1-2毫秒。

CMS和G1的问题是,在某些时候Java堆内存必须被压缩,并且这两个垃圾收集器都停止了这个世界/ STW(即暂停应用程序)来执行压缩。 因此,尽管CMS和G1可以推出STW暂停,但它们不会消除它们。 然而,Azul的C4完全消除了STW暂停,这就是为什么Zing即使对于巨大的堆大小也具有如此低的GC暂停。

为了纠正先前答案中的陈述,Zing不需要对操作系统进行任何更改。 它与未修改的Linux发行版上的任何其他JVM一样运行。

由于Java 7将默认使用新的G1垃圾回收,因此Java能够处理大一个数量级的堆而不会造成“破坏性”的GC暂停时间? 有没有人真的在生产中实施G1,你有什么经验?

公平地说,我看到真正长时间的GC暂停的时间非常长,比工作站要多得多。 澄清我的问题; G1将打开通往数百GB的网关? TB?


G1 GC应该工作得更好。 但是如果设置-XX:MaxGCPauseMillis过于积极,垃圾将收集得太慢。 这就是为什么在David Leppik的例子中触发完整的GC。


G1收集器减少了完整收集的影响。 如果您的应用程序已经减少了对完整集合的需求,那么Concurrent地图Sweep收集器同样不错,根据我的经验,缩短收集次数的时间更短。



即使您正在运行CMS,但不会累积终身对象,CMS仍可能导致性能缓慢下降。 这是因为G1本应避免的内存碎片。

关于G1的神话只有在付费的支持下才是正确的,这是一个神话。 Sun和现在的Oracle已经在JDK页面上阐明了这一点。


我一直在测试一个沉重的应用程序:60-70GB分配给堆,随时使用20-50GB。 有了这些应用程序,轻描淡写地说你的里程可能会有所不同。 我在Linux上运行JDK 1.6_22。 次要版本很重要 - 在1.6_20之前,G1中存在一些错误,导致随机的NullPointerException异常。

我发现它很好地保持了你大部分时间给予的暂停目标。 默认情况下是100ms(0.1秒)暂停,我一直告诉它做一半(-XX:MaxGCPauseMillis = 50)。 但是,一旦内存变得非常低,就会出现恐慌,并且会完全停止垃圾收集。 使用65GB,需要30秒到2分钟。 (CPU的数量可能没有什么区别;它可能受到总线速度的限制。)

与CMS(不是默认的服务器GC,但应该用于Web服务器和其他实时应用程序)相比,典型的暂停更可预测,并且可以缩短得多。 到目前为止,我在CMS上遇到了更大的运气,但这可能是随机的。 我每24小时只看到几次。 我不确定哪一个更适合我的生产环境,但可能是G1。 如果甲骨文一直在调整它,我怀疑G1最终会成为赢家。

如果您对现有垃圾收集器没有问题,现在就没有理由考虑G1。 如果您运行的是低延迟应用程序,例如GUI应用程序,则G1可能是正确的选择,MaxGCPauseMillis设置非常低。 如果您正在运行批处理模式应用程序,G1不会为您购买任何东西。


我刚刚在我们的兵马俑大记忆项目中实施了G1垃圾收集器。 虽然在不同类型的收集器G1上工作,但在不到600毫秒的响应时间内,我们获得了最佳结果。

你可以在here找到测试结果(共26个)

希望能帮助到你。


我在Java 8上使用G1GC,并在Groovy(也是Java 8)上使用G1GC,并且我正在执行各种类型的工作负载,并且整体而言,G1GC的工作方式如下所示:

  • 内存使用率非常低,例如100MB而不是500MB,与默认的Java设置相比

  • 响应时间一致且非常低

  • 在最坏的情况下使用G1GC时,默认设置与G1GC之间的性能降低20%(不需要调整,单线程应用程序)。 考虑到良好的响应时间和低内存使用情况,这并不多。

  • 从多线程的Tomcat运行时,整体性能提高30%,内存使用率也低得多,响应时间也更低。

所以总的来说,当使用真正的各种工作负载时,G1GC对于多线程应用程序来说是非常好的Java 8收集器,甚至对于单线程也有一些好处。


我正在使用Java来处理小型和大型堆,而且GC和Full GC的问题每天都会出现,因为约束可能比其他问题更严格:在某些环境中,0.1秒的清除GC或Full GC,杀(CMS,iCMS等)...目标是在接近实时处理的情况下获得最佳的响应时间(这里的实时处理通常是25毫秒) ,所以基本上,任何改善GC人机工程学和增强的方法都是值得欢迎的!


最近我已经离开了

使用JDK 1.7.45的服务器上的CMS到具有4G堆和8核心处理器的G1GC

(JDK 1.8.x G1GC优于1.7,但由于某些限制,我必须坚持1.7.45版本)

我在下面配置了关键参数,并将所有其他参数保存为默认值。

-XX:G1HeapRegionSize=n, XX:MaxGCPauseMillis=m, -XX:ParallelGCThreads=n, 
-XX:ConcGCThreads=n apart from -Xms and -Xmx

如果你想微调这些参数,看看这篇oracle文章。

主要观察:

  1. 内存使用情况与G1GC一致,不像CMS的高低不一样
  2. 与CMS相比,最大GC暂停时间更短
  3. 与CMS相比,G1GC在Garbage collection中花费的时间有点高。
  4. 与CMS相比,主要收藏数量几乎可以忽略不计
  5. 与CMS相比,次要收集数量较高

但是我仍然很高兴Max GC的暂停时间少于CMS的时间。 我已将Max GC暂停时间设置为1.5秒,并且此值尚未交叉。

相关的SE问题:

关于G1的Java 7(JDK 7)垃圾收集和文档


这听起来像G1的一点是暂停时间更短,甚至可以指定最大暂停时间目标。

垃圾收集不仅仅是一个简单的“嘿,它已经满了,让我们立刻移动所有东西并重新开始” - 再一次处理垃圾 - 这是一个非常复杂的多层次,后台线程系统。 它可以在后台进行大部分的维护工作,而且不会有任何暂停,它还可以在运行时使用系统预期模式的知识来帮助 - 例如假设大多数对象在创建后立即死亡等等。

我想说,随着未来版本的发布,GC暂停时间将会持续改善,而不会恶化。

编辑:

在重新阅读时,我想到我每天都会使用Java - Eclipse,Azureus和我开发的应用程序,而且自从我看到停顿之后,这种情况一直持续很长时间。 不是一个重大的停顿,但我的意思是任何停顿。

当我右键单击Windows资源管理器或(偶尔)连接某些USB硬件时,我看到暂停,但使用Java ---没有。

GC仍然是一个问题吗?







g1gc