QQsilhonette的博客

一. 问题现象商品团队反馈，会员部分 dubbo 接口偶现超时异常，而且时间不规律，几乎每天都有，商品服务超时报错如下图：超时的接口平时耗时极短，平均耗时 4-5 毫秒。查看 dubbo 的接口配置，商品调用会员接口超时时间是一秒，失败策略是failfast，快速失败不会重试。会员共部署了8台机器，都是 Java 应用，Java 版本使用的是 JDK 8，都跑在 docker 容器中 。二. 问题分析开始以为只是简单的接口超时，着手排查。首先查看接口逻辑，只有简单的数据库调用，封装参

1. 一个新系统开发完毕之后如何设置JVM参数原则：尽可能让那个每次Young GC后存活对象远远小于Survivor区域，避免对象频繁进入老年代触发Full GC。2. 在压测之后合理调整JVM参数Eden区对象增长速率？Young GC频率？一次Young GC耗时？Young GC过后多少对象存活？老年代对象增长速率？Full GC频率多高？一次Full GC耗时？原则：尽量避免对象频繁进入老年代3. 线上系统监控和优化4. 线上频繁F...

1. jstatjstat -gc PID 查看Java进程的内存和GC情况S0C：这是From Survivor区的大小S1C：这是To Survivor区的大小S0U：这是From Survivor区当前使用的内存大小S1U：这是To Survivor区当前使用的内存大小EC：这是Eden区的大小EU：这是Eden区当前使用的内存大小OC：这是老年代的大小OU：这是老年代当前使用的内存大小MC：这是方法区的大小MU：这是方法区的当前使用的内存大小Y..

1. 每个Region大小是多大？region的大小必须是2的倍数，默认是堆的大小除以2048。也可以手动指定"-XX:G1HeapRegionSize"2. 可以设定GC停顿时间-XX:MaxGCPauseMills3. 大对象RegionG1提供了专门的Region来存放大对象，而不是让大对象进入老年代的Region中。而且一个对象如果太大，可能会横跨多个Region来存放。大对象Region既不属于新生代也不属于老年代，在新生代、老年代回收的时候，会顺带着大对象Region

原因一：系统承载高并发请求，或者处理数据量过大，导致Young GC很贫乏，而且每次Young GC过后存活对象太多，内存分配不合理，Survivor区过小，导致对象频繁进入老年代，频繁触发Full GC。原因二：系统一次性加载过多数据进内存，搞出来很多大对象，导致频繁有大对象进入老年带，必然频繁触发Full GC。原因三：系统发生了内存泄漏，莫名其妙创建大量的对象，始终无法回收，一直占用在老年代里，必然频繁触发Full GC。原因四：Metaspace（永久代）因为加载类过多触发Full GC

1. 年轻代垃圾回收优化按照每个用户平均访问20次来计算，大致需要有500万日活用户，按照10%的付费转化率来计算，每天大概50万人会下订单，50万订单算集中在4个小时高峰期内，平均每秒就几十个订单。这时不需要对JVM多关注，内存无压力。1.1 大促场景的设定：可能在短短10分钟，瞬间会有50万订单，这样每秒会有接近1000的下单请求，按照3台来算，每台机器每秒需要抗300个下单请求，机器为4核8G，机器本身的CPU资源和内存资源是没有问题的。但是问题在于需要对JVM有限的内存资源进行合理.