共计 1550 个字符，预计需要花费 4 分钟才能阅读完成。
在高并发下，Java 程序的非正常 GC 带来的影响往往会被进一步放大。不论是「GC 频率过快」还是「GC 耗时太长」，因为 GC 期间都存在 Stop The World 问题，因而很容易导致服务超时，引发性能问题。本期小编为大家筛选了 4 篇 Young GC 问题排查文章，帮大家温习 YGC 的执行原理和问题排查要点。
1.YGC 问题排查，又让我涨姿态了！
作者：Rockets
https://heapdump.cn/article/1…
本文作者分享了一个辣手的 Young GC 耗时过长的线上案例，首先是收到服务超时告警，发现了 YoungGC 耗时过长的问题，而后就开始排查。发现问题后的解决堪称教科书般的操作：“依照 GC 问题的惯例排查流程，咱们立即摘掉了一个节点，而后通过以下命令 dump 了堆内存文件用来保留现场。jmap -dump:format=b,file=heap pid
最初对线上服务做了回滚解决，回滚后服务立马复原了失常，接下来就是长达 1 天的问题排查和修复过程。”
通过确认 JVM 配置——查看代码——对 dump 的堆内存文件进行剖析——剖析 YGC 解决 Reference 的耗时——再回到长周期对象进行剖析，找出了问题所在：每次调用 getConfig 办法时都会往 List 中增加元素，并且未做去重解决，而后立刻解决了问题。
文末对 YGC 相干知识点进行了梳理和总结，从新生代的相干常识讲起，带大家温习了 YGC 的触发机会和执行过程。
本文是一篇实践与实战联合的经典好文，作者不仅分享了本人遇到 YGC 问题的排查思路，还就此知识点帮大家温习了原理。读者今后遇到相似的问题能够参考疾速剖析解决。
2. 频繁操作本地缓存导致 YGC 耗时过长
作者：阿菜
https://heapdump.cn/article/1…
本文作者在帮群友排查 YGC 耗时过长问题，通过剖析堆栈和 GC log 发现，在某次 YGC 时，Survivor 区中年龄超过 7 的对象占用了 Survivor 空间一半以上。而失常状况下，年老代对象朝生夕死。网络服务解决申请为毫秒级，YGC 几秒甚至十几秒才产生一次, 少数年老对象活不过 1 代。于是，猜想该群友应用了本地缓存。进一步沟通后得出结论：起因一：年老代中有太多存活的对象，减少了标记工夫；起因二：YGC 又须要破费大量的工夫在扫描 Card Table 上，总结起因是操作本地缓存太频繁导致了 YGC 耗时过长。最初向群友提出了修改意见解决了问题。
在文章结尾作者还总结了该业务场景的几条批改倡议，很有参考价值。
3. 我司根底组件更新本地缓存策略问题导致 young gc 工夫升高
作者：朱纪兵
https://heapdump.cn/article/1…
本文作者在一次钻研服务 QPS 和 young gc 的工夫的关系时，发现理论状况与现实状态不同，于是开始追踪问题。用 gdb 去 dump 了下来 survivor 区域中的内容，发现了异样点。最初发现是公司配置核心根底组件更新本地缓存策略的问题。
作者遇到问题不漠视被动排查重复验证的精力值得学习。
4. 耗时 20 多秒的 young gc，你见过吗？
作者：Edenbaby
https://heapdump.cn/article/1…
作者遇到了耗时 20 多秒的 young gc，在排查时发现 user(用户耗时)+sys(零碎耗时) <real(实在耗时)，但大多数的 young GC 中，real time 是小于 sys+user time 的，因为 paralle 垃圾回收器是多线程并发的去 GC，所以 user time 是各个线程累积的一个工夫，大概率要大于 real time。因而猜想是 CPU 不够用或磁盘 IO 压力大导致的。
排查 YGC 异样问题，肯定要把握 GC 执行过程，会看 GC log，从日志中找到突破点。
更多性能文章，请拜访 https://heapdump.cn/
