浅析大促备战过程中出现的fullGc,我们能做什么?

京东云开发者
• 阅读 162

作者:京东科技 白洋

前言:

为应对618、双11大促,消费金融侧会根据零售侧大促节奏进行整体系统备战。对核心流量入口承载的系统进行加固优化,排除系统风险,保证大促期间系统稳定。 由于大促期间,消费金融业务承担着直面用户,高并发,系统风险大概率直接造成资损风险等问题。

在日常压测和大促期间,经常会发生Jvm出现大量young Gc 和 部分full GC的情况,导致性能下降,可用率降低等情况。

之前对Jvm的垃圾回收机制不是很熟,如何避免和如何调优,基本上一窍不通,本文也是对自己学到的知识的一个巩固~

一、什么是JVM的GC?

JVM(Java Virtual Machine)。JVM 是 Java 程序的虚拟机,是一种实现 Java 语言的解释器。

它提供了一种独立于操作系统的运行环境,使得 Java 程序在任何支持 JVM 的计算机上都可以运行。JVM 负责加载、验证、解释、执行和垃圾回收 Java 字节代码,并为 Java 程序提供内存管理、线程管理和安全控制等服务。

JVM 中的 GC(Garbage Collection)是垃圾回收的缩写,是 JVM 的内存管理机制。

Young GC 和 Full GC 是两种不同的 GC 算法。

Young GC:针对新生代对象的回收算法,通常使用的是复制算法或者标记整理算法。因为新生代中的对象生命周期短,所以 Young GC 速度要比 Full GC 快得多。

Full GC:针对整个堆内存的回收算法,用于回收那些在 Young GC 中没有回收的存活对象。Full GC 速度比较慢,因为它需要扫描整个堆内存,因此对系统的性能影响较大。

所以在设计 Java 应用时,需要尽量减少 Full GC 的次数,以保证系统的性能。常见的方法包括扩大新生代的内存空间,减少数组长度等。

以上基本是通用的对 Jvm 和 Gc 的解释。但是可以明显看出缺少一些细节,对我们来说还是没什么用,测试同学该如何理解具体的场景呢??

我们首先来理解young GC 的诞生过程:

首先, 理解复制算法和标记整理算法,它们是两种不同的 Young GC 回收算法。

复制算法:将新生代内存分成两个等大的部分,新创建的对象存储在一个部分,而另一个部分用于存储存活的对象。当新生代内存不够用时,Young GC 会发生,将存活的对象复制到另一个内存区域。复制算法不会导致内存碎片,但是会消耗一定的内存空间。

标记整理算法:每次 Young GC 时,会先标记所有存活的对象,然后再将所有不存活的对象整理到一起。因此,内存碎片可能会导致空间浪费。标记整理算法适用于需要保持内存空间整洁的应用,比如那些需要长时间运行的服务器应用。

这个看看就好,本质上Young Gc可以理解成jvm正常的扫垃圾过程

根据上述的解释,相信聪明的小伙伴可以清晰的看到,young Gc 有着更高的回收效率,对业务侧的影响要小的多~因此,我们进一步来看看头痛的full Gc,是怎么来的?

Full GC 是 Full Garbage Collection 的缩写,是指把整个堆内存扫描一遍,回收不再使用的对象并且整理内存的过程。由于堆内存的整体回收过程非常慢,因此,Full GC 可能导致应用程序的暂停。

如上所述,只有更合理的内存分配,避免不被使用的对象频繁出现,调整堆内存的扫描时间。

full GC, 即全垃圾回收,是一种垃圾回收的过程 它会暂停所有的应用程序线程,对整个堆进行回收。 (这个太可怕了。。)

初始标记:首先,垃圾回收器标记出哪些对象是需要被回收的。

并发标记:然后,垃圾回收器将标记任务分配给多个线程,并发地执行标记任务。

重新标记:在并发标记的过程中,如果有新的对象被创建,需要对这些对象进行重新标记。

整理:接下来,垃圾回收器将没有被标记的对象整理到内存的一端。

回收:最后,垃圾回收器回收被标记的对象,释放内存。

来个图大家看的明白一些~ Full Gc 的生命流程~ 本质上就是,垃圾太多,正常的活儿干不了了,内存空间不够了,得停下所有的事情,来一次大扫除

浅析大促备战过程中出现的fullGc,我们能做什么?

二、写代码的时候能做什么?

上述可得,fullGc是很可怕的,由于堆内存的整体回收过程非常慢,因此,Full GC 可能导致应用程序的暂停,直接就崩掉了。。。

要避免 Full GC 发生,本质上就需要对系统堆内存大小进行适当设置以及对代码进行优化,基本上有以下这些技巧:

•调整堆内存大小:确定合适的堆内存大小是避免 Full GC 发生的关键。

•对代码进行内存优化:使用不同的数据结构,避免内存泄漏,使用对象池等技巧。

•使用较大的新生代:新生代是存储短生命周期对象的内存区域,更大的新生代可以减少 Full GC 的频率。

•设置适当的垃圾回收算法:使用 G1 GC 算法等技术可以提高系统性能并减少 Full GC 的频率。

•这些是避免 Full GC 发生的一些常见建议。请注意,每种情况都不同,所以要根据具体情况选择适当的方法。

这些方法,看起来还是很抽象...我们来说点具体例子

首先,堆内存大小和垃圾回收算法,不是咱能操作和关心的,业务侧也一般不怎么会调,交给运维同学了。 浅提一下,调整内存大小:通过调整 JVM 参数,如 -Xms、-Xmx 来适当增大内存。

具体我们能做到的,最主要的就是减少数据对象的生命周期:

通过使用弱引用、软引用、虚引用等引用类型,可以在不需要数据对象时直接回收,从而避免 Full GC 。

减少数据对象的生命周期是指在程序中使用对象时,尽可能地缩短对象的存活时间。

这样可以减少垃圾对象数量,降低Full GC的频率。这是我们重点需要关注的!!

以下是一些具体的例子:

1. 避免使用不必要的临时对象:

如果程序中有大量临时对象,它们可能很快就会被垃圾回收器清理掉。因此,应该避免创建不必要的临时对象,以减少对象的生命周期。

eg:

double average(double[] values) {
    double sum = 0;
    for (double value : values) {
        sum += value;
    }
    return sum / values.length;
}

在这个例子中,数组values是临时对象,在函数结束时会被销毁。这样,不必考虑如何删除集合,以避免内存泄漏的风险。

还有,

String concatenate(List<String> strings) {
    String result = "";
    for (String str : strings) {
        result += str;
    }
    return result;
}

在这个例子中,每次循环都会创建一个临时的字符串对象,并将其附加到result中。随着循环的进行,这些临时对象可能会堆积,导致频繁的GC操作。为了避免这个问题,可以使用Java中的StringBuilder来构建字符串

String concatenate(List<String> strings) {
    StringBuilder result = new StringBuilder();
    for (String str : strings) {
        result.append(str);
    }
    return result.toString();
}

这样的话,不再需要创建临时字符串对象,从而减少GC的次数。

2. 尽早释放对象:当对象不再需要时,应该尽早将其释放,以便及时回收它。例如,在程序完成处理后立即释放对象,而不是等到下一次需要使用它之前。

比如我们日常最常用的for循环就很棒,

for (int i = 0; i < data.length; i++) {
  // do something with data[i]
}

在这个例子中,循环变量 i 只在循环中使用,并在循环结束后释放。这样做可以减少不必要的内存使用,从而减少全垃圾回收的次数。

另一个具体的例子是使用 try-with-resources 语句,这可以确保流等资源在不再使用后自动关闭,例如:

try (FileInputStream in = new FileInputStream("file.txt")) {
  // use the input stream
} catch (IOException e) {
  // handle exception
}

在这个例子中,文件输入流在不再使用后会被自动关闭,就不用手动关,这样也会更合理~

3. 重复使用对象:如果可以,可以尝试重复使用同一个对象,而不是频繁地创建和销毁新的对象。

这个比较好理解,比如同样的事务流程,没必要搞两个变量 ~ 最少的变量干最多的活儿是最理想的~

4. 使用对象池:

可以使用对象池,重复使用固定数量的对象,而不是不断创建新的对象。这样可以减少对象的生命周期,并降低Full GC的频率。

使用对象池是一种常用的避免Full GC的方式。它的核心思想是重复利用已经创建好的对象,而不是每次都创建新的对象。

以下是一个简单的对象池的代码例子:

import java.util.ArrayList;
import java.util.List;

public class ObjectPool {
  private static final int POOL_SIZE = 100;
  private static final List<Object> pool = new ArrayList<>(POOL_SIZE);
  static {
    for (int i = 0; i < POOL_SIZE; i++) {
      pool.add(new Object());
    }
  }
  public static Object getObject() {
    if (pool.isEmpty()) {
      return new Object();
    }
    return pool.remove(0);
  }
  public static void returnObject(Object object) {
    pool.add(object);
  }
}

在代码中,我们创建了一个大小为100的对象池,并在静态代码块中初始化了100个对象。当我们需要使用对象时,可以调用getObject方法,如果对象池中有剩余的对象,就从对象池中取出一个对象;如果没有剩余对象,就新建一个对象。当不需要这个对象了,就可以调用returnObject方法,将对象放回对象池中。

这样,我们可以重复利用已经创建好的对象,减少了对象的创建和销毁的频率,从而减少了Full GC的几率。

5. 使用弱引用:

在程序中,如果有大量对象不会再使用,可以使用弱引用来引用它们。 这个最多应用在类型缓存这样的场景,它们不是必须的对象,因此有些时候可以直接干掉

这是一个弱引用的例子,这玩意儿还是比较抽象的。。。

import java.lang.ref.WeakReference;

public class WeakReferenceExample {
    public static void main(String[] args) {
        Object obj = new Object();
        WeakReference<Object> weakRef = new WeakReference<>(obj);

        obj = null;
        System.gc();
        if (weakRef.get() != null) {
            System.out.println("Object is still alive");
        } else {
            System.out.println("Object has been garbage collected");
        }
    }
}

举个更具体点的:

import java.lang.ref.WeakReference;
import java.util.HashMap;

public class WeakReferenceExample {
  public static void main(String[] args) {
    HashMap<String, WeakReference<MyObject>> cache = new HashMap<>();
    MyObject obj = new MyObject("example");
    cache.put("example", new WeakReference<>(obj));
    obj = null;
    System.gc();
    System.out.println(cache.get("example").get());
  }

  static class MyObject {
    String name;

    public MyObject(String name) {
      this.name = name;
    }

    @Override
    public String toString() {
      return "MyObject{" + "name='" + name + ''' + '}';
    }
  }
}

这个例子中,我们将一个MyObject对象封装在弱引用中,并保存在HashMap缓存中,当我们显式调用System.gc()方法时,JVM会尝试回收这些不再使用的对象,如果内存不足,则会回收MyObject对象,那么cache.get("example").get()返回的将是null。

三、测试能做啥

回顾全文,其实我们能做的真不多,只能在业务代码测试的过程中,关注对象的使用频次,拒绝无效的引用或new一大堆没必要的对象。

具体手段

定期监测 GC 日志:通过我们的jvm关注,大项目上线后,或代码改动特别大的项目上线后,做一下读写压测的操作~

浅析大促备战过程中出现的fullGc,我们能做什么?

数据结构优化: 根据上述的手段,测试开发工程师可以通过上述手段,来优化数据结构来减小数据对象的生命周期,从而避免 Full GC。在测试过程中,关注一下数据结构的合理性~

关注单元测试:通过运行研发的单元测试,或自己手动写一个,模拟实际的内存使用情况,来评估内存的使用情况(基本上,目前的业务代码能跑起来,大概率是没问题的,,)

总结:

日常的业务代码测试,对内存的敏感度要高一些,没bug不一定不会出问题,现在我们的系统是成熟的可靠的,但是面对大促的压力,如果能提前解决隐患,干掉有风险的内存使用,也是节省我们压测时的工作量嘛~

点赞
收藏
评论区
推荐文章
blmius blmius
2年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
京东物流常态化压测实践 | 京东云技术团队
大促备战压测备战时间紧、任务多,压测备战压力较大,在大促备战多专项并行资源紧张情况下,频繁的系统调优给整个大促带来不可控的风险因素。引入常态化压测的手段,通过每周或每月的定期压测行为,持续把控系统性能表现,保证服务稳定性;同时将需求上线引起的性能问题前置暴露,及时定位优化问题;减轻备战压力,提升压测效率。
Wesley13 Wesley13
2年前
VBox 启动虚拟机失败
在Vbox(5.0.8版本)启动Ubuntu的虚拟机时,遇到错误信息:NtCreateFile(\\Device\\VBoxDrvStub)failed:0xc000000034STATUS\_OBJECT\_NAME\_NOT\_FOUND(0retries) (rc101)Makesurethekern
Wesley13 Wesley13
2年前
FLV文件格式
1.        FLV文件对齐方式FLV文件以大端对齐方式存放多字节整型。如存放数字无符号16位的数字300(0x012C),那么在FLV文件中存放的顺序是:|0x01|0x2C|。如果是无符号32位数字300(0x0000012C),那么在FLV文件中的存放顺序是:|0x00|0x00|0x00|0x01|0x2C。2.  
Stella981 Stella981
2年前
SpringBoot整合Redis乱码原因及解决方案
问题描述:springboot使用springdataredis存储数据时乱码rediskey/value出现\\xAC\\xED\\x00\\x05t\\x00\\x05问题分析:查看RedisTemplate类!(https://oscimg.oschina.net/oscnet/0a85565fa
Wesley13 Wesley13
2年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Wesley13 Wesley13
2年前
PHP创建多级树型结构
<!lang:php<?php$areaarray(array('id'1,'pid'0,'name''中国'),array('id'5,'pid'0,'name''美国'),array('id'2,'pid'1,'name''吉林'),array('id'4,'pid'2,'n
Easter79 Easter79
2年前
SpringBoot整合Redis乱码原因及解决方案
问题描述:springboot使用springdataredis存储数据时乱码rediskey/value出现\\xAC\\xED\\x00\\x05t\\x00\\x05问题分析:查看RedisTemplate类!(https://oscimg.oschina.net/oscnet/0a85565fa
Wesley13 Wesley13
2年前
Java日期时间API系列36
  十二时辰,古代劳动人民把一昼夜划分成十二个时段,每一个时段叫一个时辰。二十四小时和十二时辰对照表:时辰时间24时制子时深夜11:00凌晨01:0023:0001:00丑时上午01:00上午03:0001:0003:00寅时上午03:00上午0
Wesley13 Wesley13
2年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_