从Java虚拟机小测的结果来看JVM | KAAAsS's blog
不仅如此，CMS还有很多其他的缺点。不过这里空白太小，我写不下。而且，虽然CMS+ParNew依然是很常用的一种搭配，CMS也将步入历史的尘埃了。JEP 291[1]提到了在未来Java版本中去除CMS收集器的计划，而且该JEP已经被列入JDK 9[2]中。现在你使用CMS收集器的话将会得到一句警告。而废弃CMS的原因很幽默，就是现任维护者Christoph Engelbert看不懂原先CMS复杂晦涩的代码（参见邮件[3]）。（话说我在领英上看到，CMS的自适应freelist是JEP的提出者Jon Masamitsu制作的，你为啥不接锅？）不过这个JEP也激起了广泛的讨论。CMS如今在一些内存较小的设备（如树莓派）中有非常不错的性能，而作为替代的G1收集器（后文介绍）在这种情况下的性能并不好。而且由于CMS的侧重点不同，CMS的收集时间比G1要更少。不过随着G1的逐渐改善，相信这种差距会逐渐缩小，甚至于G1完全替代CMS。不过其实除了早期Sun实验室的吹笔论文[4]，似乎也没有完整的针对JDK 9的CMS与G1对比，我在StackOverflow和Reddit上看了很多讨论，基本上都是嘴巴压测。（而且就算是Sun的论文，CMS也是有优势。不过，我这里倒是找到一篇简单对比的[5]，可惜比较早）嘛，我在此号召各位有志青年与各路大神快去阅读OpenJDK，然后发起#Save CMS#。好在另一份邮件[6]提到移除CMS是一个漫长的过程，所以暂时似乎还能用着CMS过日子？
G1收集器是船全新的，也是最新的收集器，在JDK 7u4之后已经完全开放商用了。它是标记-整理算法与复制算法的一种结合，而这种结合建立在将内存分为一个个Region的基础上。G1能同时作用于新生代和老年代，而且进一步的讲，G1收集器直接作用于整个Java堆！从上面那些邮件中，开发者吹爆G1的态度可以看出，众开发者可是对G1寄予厚望的。不过我看到吐槽G1的声音依然不少（甚至有说"Use G1 when you have tons of memory and don't care about burning CPU… 😉
Read full article from 从Java虚拟机小测的结果来看JVM | KAAAsS's blog
No comments:
Post a Comment