高并发下，Java程序异常GC的影响往往会被进一步放大。无论是“GC频率过快”还是“GC时间过长”，由于GC时的StopTheWorld问题，很容易造成服务超时，造成性能问题。本期小编为大家筛选了4篇YoungGC排查文章，帮助大家回顾YGC的实现原理和排查要点。1.解决YGC问题让我重新站起来了！作者：Rocketshttps://heapdump.cn/article/1...本文作者分享了一个YoungGC耗时过长的棘手在线案例。首先，他收到服务超时告警，发现是YoungGC耗时过长的问题，开始排查。发现问题后的处理堪称教科书般的操作：“按照GC问题的正常排查流程，我们立即移除了一个节点，然后使用如下命令dump堆内存文件以保全现场。jmap-dump:format=b,file=heappid终于回滚了线上服务，回滚后服务立即恢复正常，随后进行了为期一天的排查修复过程。”确认JVM配置后——查看代码——分析dump的堆内存文件——分析YGC对Reference的耗时处理——然后返回长周期对象进行分析，发现问题所在：每次调用getConfig方法，都会往List中添加元素，不用去重，立马解决问题。文末对YGC的相关知识点进行了梳理和总结。从相关的开始新生代的知识，带大家回顾一下YGC的触发时机和执行过程，这篇文章是一篇理论与实践相结合的经典好文，作者不仅分享了遇到YGC问题时的排查思路，还帮助大家回顾基于该知识点的原理，以后遇到类似问题的读者可以参考快速分析解决2.频繁操作本地缓存导致YGC耗时过长发现在某一次YGC过程中，对象较旧Survivor区的7个以上占据了Survivor空间的一半以上。一般情况下，新生代对象生死存亡。Web服务在毫秒级别处理请求，而YGC只在几秒甚至十几秒内发生一次，大多数年轻对象无法存活一代。因此猜测群友使用了本地缓存。经过进一步的沟通，我们得出了一个结论：原因1：年轻代存活对象过多，增加了markingtime；原因二：YGC需要花费大量时间扫描牌桌。原因是本地缓存操作过于频繁。YGC花了太长时间。最后群友提出修改，解决问题。在文章的最后，作者还总结了几点修改业务场景的建议，很有参考价值。3.我司基础组件更新本地缓存策略，导致younggc时间增加。作者：朱继兵https://heapdump.cn/article/1...本文作者在研究服务QPS与younggc时间的关系时，发现实际情况与理想状态不同，所以我们开始追查问题。用gdb把survivor区的内容dump出来，找出异常点。最后发现是公司配置中心基础组件更新了本地缓存策略。作者遇到问题不忘主动调查、反复验证的精神值得学习。4、你见过耗时20多秒的younggc吗？作者：Edenbabyhttps://heapdump.cn/article/1...作者遇到一个younggc耗时20多秒，发现user（用户耗时）+sys（系统耗时）
