做网站送推广,贵州网站建设设计公司哪家好,wordpress链接数据库间歇出错,网站备案个人信息在针对JDK 9#xff08;2017/4/4#xff09;提出的JEP中 #xff0c; Mark Reinhold写道JEP 291 #xff08;“弃用并发标记扫描#xff08;CMS#xff09;垃圾收集器”#xff09;是“已被放入“建议的在讨论和审查后#xff0c;由所有者将其定位为目标”。 如果JEP 2… 在针对JDK 92017/4/4提出的JEP中 Mark Reinhold写道JEP 291 “弃用并发标记扫描CMS垃圾收集器”是“已被放入“建议的在讨论和审查后由所有者将其定位为目标”。 如果JEP 291一切顺利它将针对JDK 9。 Reinhold在此消息中解释了为何在相对较晚的日期仍然可以将JEP 291定位到JDK 9“ JEP 291仅需要微小的代码更改即可发出建议的警告消息。 首先这是一个JEP不是因为这是一个冒险的更改而是要从长远来看使计划具有可见性以删除CMS收集器。” 正如这些语句所指出的那样JDK 9的针对性操作只是将并发标记扫描CMS收集器标记为已弃用其想法是“从长远来看”将在某个时候将其删除。 尽管G1GC是JDK 9到JEP 248的默认垃圾收集器 但它并不总是适用于所有情况的最佳垃圾收集器。 甚至不建议使用CMS的提议在其“ 风险和假设 ”中也承认了这一点其中指出“对于某些应用程序CMS非常适合并且可能总是优于G1。” 关于OpenJDK jdk9-dev邮件列表的另一个最新讨论的标题为“ JEP 291弃用并发标记扫描CMS垃圾收集器”其中包含有关保留CMS的有趣论点。 Christoph EngelbertHazelcast 写道 “ CMS ParNew是最常用的解决方案并且许多应用程序都针对CMS的行为进行了优化。” 斯科特·帕尔默 Scott Palmer 写道 “在他的特定应用中“到目前为止我们发现CMS收集器的最大暂停时间远低于G1。” Roman KennkeRedHat 补充说 “我说谈论删除CMS还为时过早。 而且老实说我什至质疑过时的举动。” Martijn VerburgjClarity表示“我们现在不断被要求为客户调整G1并且发现即使使用我们最先进的分析结合一些常见且更深奥的调整选项我们也无法使G1达到在某些情况下优于CMS。 因此一些客户已经恢复使用CMS并且对CMS的未来作为消费者非常感兴趣。” 相同的讨论还包括不建议使用CMS的原因。 马克·雷因霍尔德Mark Reinhold的帖子指出JEP 291是“去年夏天发布的”并要求提供CMS维护者但“到目前为止没有人加紧。” 他总结说“无论如何Oracle确实打算在不远的将来停止维护CMS如果没有人上任我们将删除代码。” Jeremy MansonGoogle 解释了G1GC和CMS当前情况的棘手问题 我们决定在尝试让G1做我们需要做的事情之后以任何一种持续的方式支持CMS应该是最后的选择。 我们相信收藏家越少越好。 在过去的几个月中我们花了一些时间与Oracle的一些人员进行协调并进行实验以查看G1是否有可行的前进方法。 我们找不到明显的东西。 这一切的主旨似乎是许多应用程序仍依赖于CMS并且这些应用程序将在JDK 9中显示已弃用警告。CMS垃圾收集器的未来似乎令人怀疑但仅在JDK 9中才会弃用。何时真正删除CMS收集器似乎不太明显但是我认为JDK 10是潜在的“未来主要发行版”其中CMS支持可以终止。 再次引用曼森Google的话“简短的是我们仍然愿意为支持CMS做出贡献但是我们要确保首先对G1进行了尽职调查。 我们一直认为JDK 10时间框架足够长因此我们不必着急做出此决定。” 使用JDK9中的并发标记扫描垃圾收集器的Java应用程序似乎将看到有关CMS垃圾收集器已弃用的警告消息。 何时或是否根本无法使用CMS不太明显而取决于谁愿意继续支持CMS。 翻译自: https://www.javacodegeeks.com/2017/04/java-garbage-collectors-will-g1gc-force-cms.html
