在高并发下，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/