长沙 网站设计 公司,企业网服务器如何搭建,住建局查询系统,中国十大it外包公司垃圾收集算法,垃圾收集器我们的研究实验室正全速前进。 随着最近的资本注入 #xff0c;我们只能保证我们不断创新的步伐只会加快。 我们进行的部分研究与GC优化有关。 在处理这个有趣的领域中的问题时#xff0c;我们认为可以分享一些有关GC算法使用的见解。 为此#xff… 垃圾收集算法,垃圾收集器 我们的研究实验室正全速前进。 随着最近的资本注入 我们只能保证我们不断创新的步伐只会加快。 我们进行的部分研究与GC优化有关。 在处理这个有趣的领域中的问题时我们认为可以分享一些有关GC算法使用的见解。 为此我们对使用特定GC算法的频率进行了研究。 结果有些令人惊讶。 让我从数据的背景开始–我们可以访问来自84,936个会话的数据这些会话代表2670种不同的环境用于研究。 13的环境明确指定了GC算法。 其余的决定权交给了JVM。 因此在使用显式GC算法的11,062会话中我们能够区分出六种不同的GC算法 在了解有关GC算法用法的详细信息之前我们应该停一分钟然后尝试理解为什么上面的饼图中缺少87的运行。 我们认为这是两个不同根本原因的征兆 首先也是有充分理由的是– JVM在选择合理的默认值方面已经表现出色以至于开发人员不再需要深入研究。 如果您的应用程序吞吐量和延迟足够那么–为什么要打扰 缺少GC算法的第二个可能原因表明应用程序性能并不是团队的首要任务。 正如我们去年的案例研究所表明的那样仅需调整一项配置即可显着提高吞吐量和延迟。 因此我们有将近83,000个使用默认GC选择运行的JVM。 但是默认值是什么 答案既简单又复杂。 如果认为您正在客户端JVM上运行则JVM所应用的默认值为串行GC-XX UseSerialGC。 在服务器级计算机上默认值为并行GC-XX UseParallelGC。 可以基于以下决策表确定是在服务器还是客户端类计算机上运行 建筑 CPU /内存 操作系统 默认 i586 任何 微软视窗 客户 AMD64 任何 任何 服务器 64位SPARC 任何 的Solaris 服务器 32位SPARC 2个以上内核和 2GB RAM 的Solaris 服务器 32位SPARC 1核或2GB RAM 的Solaris 客户 i568 2个以上内核和 2GB RAM Linux或Solaris 服务器 i568 1核或2GB RAM Linux或Solaris 客户 但是让我们回到在配置中已明确指定GC算法的13的人。 它以良好的旧串行模式开始毫无疑问它的用户群如此之小以至于在上图中几乎看不到它。 实际上只有31个环境确定这是最佳的GC算法并且已明确指定了该算法。 考虑到当今大多数平台都在多核计算机上运行您应该不会感到惊讶–当您拥有多个核时几乎总是建议从串行模式切换。 GC 计数 序列号 31 平行 1,422 平行旧 1,193 ConcMarkSweep 6,655 CMSIncrementalMode 935 G1 826 其余配置可以分为三组-并行并发和G1。 赢家是显而易见的-并发标记和扫描算法相结合构成了样本的三分之二以上。 但是让我们更深入地研究结果。 Parallel和ParallelOld模式大致在同一邻域中具有1,422和1,193个样本。 不足为奇–如果您确定并行模式适合您的年轻一代那么对于老一代而言相同的算法通常也表现良好。 并行模式中另一个有趣的方面是–从上面可以看出并行模式是大多数常见平台上的默认模式因此缺乏明确的规范并不意味着它不比其他模式流行。 对于CMS我们的期望有所不同。 即–与具有6556种配置的传统CMS相比增量模式仅在935次打开。 提醒您-在并发阶段垃圾收集器线程正在使用一个或多个处理器。 增量模式用于通过定期停止并发阶段以使处理器退还给应用程序来减少长时间的并发阶段的影响。 这样可以缩短暂停时间尤其是在处理器数量少的机器上。 目前尚不清楚环境是全部拥有海量核心还是负责配置的人员都不知道增量模式的好处。 但是我们最大的惊喜与G1的采用率有关。 G1作为垃圾收集算法正在运行826个环境。 根据我们的经验无论您是追求吞吐量还是等待时间G1的表现都比CMS差。 也许我们可以访问的测试用例的选择不多但是目前我们认为G1需要更多的时间来实际兑现其承诺。 因此如果您是快乐的G1用户也许可以与我们分享您的经验 参考 您正在使用什么垃圾收集器 由我们的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上获得。 翻译自: https://www.javacodegeeks.com/2013/11/what-garbage-collector-are-you-using.html垃圾收集算法,垃圾收集器
