垃圾回收是非常必要的,但是如果处理不好,它会成为性能杀手。采取以下步骤以确保 GC 停顿时间最少且最短。
Java
最近有个同学说他的服务刚启动就收到两次 Full GC 告警, 按道理来说刚启动,对象应该不会太多,为啥会触发 Full GC 呢?
在文章 JVM 源码解读之 CMS GC 触发条件 中分析了 CMS GC 触发的五类情况,并且提到 CMS GC 分为 foreground collector 和 background collector。 不管是 foreground collector 还是 background collector 使用的都是 mark-sweep 算法,分阶段进行标记清理,优点很明显-低延时,但最大的缺点是存在碎片,内存空间利用率低。因此,CMS 为了解决这个问题,在每次进行 foreground collector 之前,判断是否需要进行一次压缩式 GC。
经常有同学会问,为啥我的应用 Old Gen 的使用占比没达到 CMSInitiatingOccupancyFraction 参数配置的阈值,就触发了 CMS GC,表示很莫名奇妙,不知道问题出在哪?
本篇原文来自 LinkedIn 的 Zhenyun Zhuang,原文:Application Pauses When Running JVM Inside Linux Control Groups[1],在容器化的进程中,或多或少会对现有应用程序带来一些问题,这篇文章讲的是 LinkedIn 在使用 cgroups 构建容器化产品过程中,发现资源限制策略对 Java 应用程序性能会产生一些影响,文章深入分析问题根本原因,并给出解决方案。笔者看过后,觉得非常赞,因此翻译后献给大家,希望对大家有帮助。
本篇原文作者是 LinkedIn 的 Swapnil Ghike,这篇文章讲述了 LinkedIn 的 Feed 产品的 GC 优化过程,虽然文章写作于 April 8, 2014,但其中的很多内容和知识点非常有参考意义。因此,翻译后献给各位同学。 原文链接:Garbage Collection Optimization for High-Throughput and Low-Latency Java Applications。
前几天这篇《一个 JVM 参数引发的频繁 CMS GC》文章发出之后,反应比较激烈,因为这可能与同学们通常 GC 优化经验相悖,通常有很多业务都通过添加 -XX:+CMSScavengeBeforeRemark 参数,来降低 CMS-remark 的时间,进而提升业务的性能以及可用性。
了解 CMS GC 的同学,一定知道 -XX:CMSScavengeBeforeRemark 参数,它是用来开启或关闭在 CMS-remark 阶段之前的清除(Young GC)尝试。
博客已经好久没有更新了,主要原因是 18 年下半年工作比较忙,另外也没有比较有意思的题材,所以迟迟没有更新。 此篇是 18 年底的微信上的某同学提供的一个 Young GC 问题案例,找我帮忙解决。这个 GC 案例比较有意思,虽然过去有一段时间了,但是想想觉得还是有必要写出来,应该对大家很有帮助。 排查问题有点像侦探断案,先分析各种可能性,再按照获得的一个个证据,去排除各种可能性、然后定位原因,最终解决问题。
GC 优化关键是找到优化的点,如果明确 GC 过程中耗时的阶段在哪里,优化起来应该也就不难了。这篇文章主要讲述最近一次 CMS GC 优化过程,是一次分享,也是一次总结。闲话少说,我们开始吧。