您现在的位置是：首页 > 文章详情

跑的好好的 Java 进程，怎么突然就瘫痪了

日期：2019-12-10点击：519收藏

内存回收一直是 Java的痛点

用 Java 无法做出类似 Redis 这样的产品。Java 的内存回收机制使我们在编写代码时不需要关注对象的回收，同时加大了内存回收的消耗，标记复制需要做内存拷贝，标记清除算法则需要 stop the world 。所以我们在使用缓存的时候，量稍微大一些就需要借助类似 Redis 这样的中间件帮我们处理了。作为 Javaer ，我们享受了自动内存回收的安逸，同时也需要多了解下内存优化的方法。

为什么 FGC 停不下来了

什么情况下会 GC

为了了解我们的系统为什么会不停 FGC ，我们需要先了解一下系统什么情况下会 GC 。在 Jvm 层面，当我们 new 一个对象的时候， Jvm 会先在堆区分配对象需要的内存，这个时候如果内存不够的话，就需要 GC 了， GC 的返回结果就是对象的空间地址。Jvm 会先进行 ygc ，也就是我们通常说的标记复制，如果 ygc 之后依然申请不到空间，就会进行 FGC 了。同理，如果 FGC 之后依然没有足够的空间，就会循环的进行 FGC ，直到申请到足够的空间。

导致不停的 FGC 的原因

如上文所讲， FGC 有可能发生在你的每一行代码。如果 FGC 之后依然没有足够的空间，就会不停的 FGC ，直到申请到足够的空间。同时 JVM 会限制在抛出 OutOfMemory 错误之前在 GC 中花费的 VM 时间的比例。系统频繁 F 大致有五种情况：

内存泄漏
请求处理变慢导致同时申请内存的线程太多
metaspace 耗尽
常量池将堆区占满
堆外内存耗尽

在一个高并发的系统中，多数 FGC 是请求处理变慢导致的。假设单机承受 tps 是1w，正常情况下处理一个请求的时间是 1ms ，那同一时刻并行的请求数量仅为 10 。如果性能发生抖动，每个请求处理的时间增加到 100ms ，那同一时刻并行的请求数量就会增加到 100 个。每个线程在处理请求的时候都会 new 一些对象出来，长时间存活的线程会造成类似内存泄漏的效果，将系统的内存耗尽。同时 FGC 也会加剧系统性能的开销，使系统变得更慢，产生雪崩。

如何让系统 FGC 之后仍然能活下来

杜绝内存泄漏

内存泄漏产生的原因以及解决办法网上有很多资料，这里就不写了。内存泄漏造成系统瘫痪的频率很高，有些系统定时从数据库拉取配置信息缓存到集合中，但是 set 不小心写成了 list ，最终在新增元素的时候内存溢出了。养成良好的编程习惯，多关注些细节，就能避免很多未知的问题。

并发限制：防止系统被撑死

每台服务器都有并行处理请求的上限，不管请求处理的多快，超过上限之后就会被撑死，对高并发的请求做好并发数限制是保持系统稳定的必要条件。需要注意的是，有一些系统在拒绝过多的请求时，也会做一些降级逻辑，降级逻辑也是有性能开销的，同样需要做并发限制，如果降级的请求超过并发限制，将不进行降级逻辑直接抛出异常。

自适应限流：防止系统被摸死

我们需要自适应限流有两个原因：

每台服务器所处的环境是不一样的

有些服务器和离线计算的 vm 混部在一起，有些部署在实体机，有些部署在新老型号的机器上，每台服务器能承受的 qps 并不完全一样。统一配置分布式系统中每台服务器限流阀值，要么发挥不出每台服务器应有的作用，要么在高 qps 的情况下一些比较慢的服务器宕机，所以用服务器作为限流粒度是最合适的。

设置了正确的限流阀值，也可能被摸死

当单机承受的 QPS 6~20 倍于限流的流量时，拒绝一次请求的开销就无法忽略不记了。譬如春晚活动有些系统设置了正确的限流也被 6~20 倍于限流的流量冲垮。这种死法称为被摸死。应对这种情况，我们可以做的是在受到 6~20 倍的大流量时，动态减少限流的阀值。比如系统最开始接受 1000qps ，5000 的拒绝流量过来会把系统摸死，这个时候我们调整系统的阀值，限流设置到 100 ，被摸死的阀值就可以高一些，这样就算有 6000 个请求进来，我们系统也可以保证活下来。

阿里有结合算法动态调整单机限流阀的产品，已经对外公布了，感兴趣的同学可以搜一下淘系技术公众号中的诺亚自适应限流的相关内容。