性能文章>大量类加载器创建导致诡异FullGC>

大量类加载器创建导致诡异FullGC原创

1年前
7331316

现象

最近接手了一个同事的项目,某一天接口的响应耗时突然增加了很多,由几十ms 增加到了几十秒。

首先查看机器上的日志,有调用第三方接口超时,查询数据库超时。立马查看第三方接口监控和数据库监控,一切正常。可能由于 GC 停顿造成统计的超时,这个时候我们通过 jstat -gcutil pid 查看 gc 情况。数据如下:

  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT
  0.00   0.00   3.88  12.86  76.39  45.62    211    8.574   892  626.192  634.767
  0.00   0.00   4.10  12.86  76.39  45.62    211    8.574   893  626.192  634.767
  0.00   0.00   0.00  12.88  76.39  45.62    211    8.574   894  626.915  635.489
  0.00   0.00   0.11  12.88  76.39  45.62    211    8.574   896  627.678  636.253
  0.00   0.00   0.00  12.87  76.39  45.62    211    8.574   897  628.926  637.500
  0.00   0.00   0.00  12.87  76.39  45.62    211    8.574   899  630.381  638.956
  0.00   0.00   1.92  12.87  76.39  45.62    211    8.574   901  631.155  639.729
  0.00   0.00   0.00  12.87  76.39  45.62    211    8.574   902  632.379  640.954
  0.00   0.00   2.14  12.87  76.39  45.62    211    8.574   903  633.094  641.668
  0.00   0.00   0.00  12.88  76.39  45.62    211    8.574   904  633.859  642.433

这里我们可以看到年轻代(E) 使用率很小,老年代(O)使用率 12% 也不多,M(Metaspace) 使用率 76.39% 也没占满,Yong GC 没有变化,Full GC 一直在进行,每次耗时800多ms。结合前面 E、O 和 M 使用率都没有变化,说明内存一直回收不掉。

JVM 内存大小相关配置如下:

 -Xms3g -Xmx3g -Xmn1g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m

接下来我们看下 GC 日志:

2020-08-13T23:11:00.352+0800: 214929.371: [GC (CMS Initial Mark)  276144K(3040896K), 0.0405942 secs]
2020-08-13T23:11:00.886+0800: 214929.905: [Full GC (Metadata GC Threshold)  290482K->275966K(3040896K), 0.7939954 secs]
2020-08-13T23:11:01.693+0800: 214930.712: [Full GC (Last ditch collection)  275966K->275964K(3040896K), 0.8086755 secs]
2020-08-13T23:11:02.520+0800: 214931.539: [Full GC (Metadata GC Threshold)  295199K->273816K(3040896K), 0.8332017 secs]
2020-08-13T23:11:03.366+0800: 214932.385: [Full GC (Last ditch collection)  273816K->273799K(3040896K), 0.7748226 secs]

GC 日志中有 Metadata GC Threshold ,结合前面 Metaspace 使用率最高我们猜测可能是 Metaspace 溢出了,然后我们在日志中 grep OutOfMemory 关键字,有如下报错:

java.lang.OutOfMemoryError: Metaspace

至此可以确认是 Metaspace 出问题了,但是为什么 jstat 输出的使用率只有 76.39% 呢?大家如果经常使用 jstat 看一下正常的程序就会很多正常情况 Metaspace 都占用 90% 以上。

Metaspace

Metaspace 元数据空间,专门用来存储类的元数据,它是 JDK8 中用来替代 Perm 的特殊数据结构。

Metaspace 空间被分配在本地内存中(非堆上),默认不限制内存使用,可以使用 MaxMetaspaceSize 指定最大值。MetaspaceSize 指定最小值,默认 21 M。通过 mmap 来从操作系统申请内存,申请的内存会分成一个一个 Metachunk,以 Metachunk 为单位将内存分配给类加载器,每个 Metachunk 对应唯一一个类加载器,一个类加载器可以有多个 Metachunk 。

可以用 java -XX:+PrintFlagsFinal -version 来查看 JVM 的默认参数值

在 Java 虚拟机中,每个类加载器都有一个 ClassLoaderData 的数据结构,ClassloaderData 内部有管理内存的 Metaspace,Metaspace 在 initialize 的时候会调用 get_initialization_chunk 分配第一块 Metachunk,类加载器在类的时候是以 Metablock 为单位来使用 Metachunk。

//classLoaderData.hpp
class ClassLoaderData : public CHeapObj<mtClass> {
...

  Metaspace * _metaspace;  // Meta-space where meta-data defined by the
                           // classes in the class loader are allocated.
  Mutex* _metaspace_lock;  // Locks the metaspace for allocations and setup.

...
}

// metaspace.hpp
class Metaspace : public CHeapObj<mtClass> {
...
 private:
  void initialize(Mutex* lock, MetaspaceType type);
  
  Metachunk* get_initialization_chunk(MetadataType mdtype,
                                      size_t chunk_word_size,
                                      size_t chunk_bunch);
...
}

// metachunk.hpp
class Metachunk : public Metabase<Metachunk>
class Metablock : public Metabase<Metablock>

// MetablockMetachunk 的父类
template <class T>
class Metabase VALUE_OBJ_CLASS_SPEC {
  size_t _word_size;
  T*     _next;
  T*     _prev;
...
}

下图所示是每个类加载器分配内存结构。

image.png

接下来我们讲下什么时候会触发 FullGC,有个参数 MinMetaspaceFreeRatio(默认40) ,当满足如下条件就会进行 GC,如果当前需要申请的内存比剩余可以 commit 的空间还要大,如果还没有达到 MaxMetaspaceSize 的话,会触发扩容。

剩余可以 commit 的空间大小 < (commited 大小 * MinMetaspaceFreeRatio)

上面说到 commited 的内存,这里还有几个概念 :used、capacity、reserved,如下图所示

  • used: chunk 中已经使用的 block 内存,这些 block 中都加载了类的数据。

  • capacity:在使用的 chunk 内存。

  • commited:所有分配的 chunk 内存,这里包含空闲可以再次被利用的。

  • reserved:是可以使用的内存大小。

image.png

如下所示,是打印出来的内存信息,最后一行是开启压缩指针(64位压缩为32位)后,Metaspace 中专门存放 kclass 的信息。

Heap
 par new generation   total 30720K, used 1519K [0x00000007f8600000, 0x00000007fa750000, 0x00000007fa750000)
  eden space 27328K,   5% used [0x00000007f8600000, 0x00000007f877bcc8, 0x00000007fa0b0000)
  from space 3392K,   0% used [0x00000007fa400000, 0x00000007fa400000, 0x00000007fa750000)
  to   space 3392K,   0% used [0x00000007fa0b0000, 0x00000007fa0b0000, 0x00000007fa400000)
 concurrent mark-sweep generation total 68288K, used 21614K [0x00000007fa750000, 0x00000007fea00000, 0x00000007fea00000)
 Metaspace       used 23505K, capacity 30704K, committed 30720K, reserved 1073152K
  class space    used 3341K, capacity 7550K, committed 7552K, reserved 1048576K

基础知识讲完了,现在我们回到开头,我们通过 jstat 打印出的 M 是怎么计算的呢?这里使用率并不是我们理解的整个 Metaspace 内存的使用率。

M = used / commited

所以 Metaspace 内存溢出了,使用率也才 76%,有两种可能:

  1. 这次分配的内存达到了 61M( 256M*24% ) 以上?

  2. 给类加载器分配的 chunk 使用率很低?

第一种显然不太可能,一个类不可能需要这么大的内存。第二种有种情况,当创建很多类加载器,而每个类加载器又加载了很少的类。

上面我们说了剩余空闲内存小于metaspaceGC的阈值就会执行FullGC,但是我们开头说有些正常场景我们通过 jstat 打印的使用率都达到了 90% 多都没有触发 FullGC,这是为什么呢?欢迎留言分享你的答案

排查程序

首先,我们看下 Metaspace 加载的到底是哪些类

jcmd pid GC.class_stats |awk '{print $13}'| sort | uniq -c |sort -r| head

通过 jcmd 查看加载的类,然后统计数量,我们看到,Script1 被加载了两万多次,按 JVM 类加载的双亲委派方式,一个类最多被加载一次,这里出现了多次,可能是不同的类加载器加载的。

27348 Script1
   3
   2 ClassName
   1 sun.util.spi.CalendarProvider
   1 sun.util.resources.en.TimeZoneNames_en
   1 sun.util.resources.en.CurrencyNames_en_US
   1 sun.util.resources.en.CalendarData_en
   1 sun.util.resources.TimeZoneNamesBundle
   1 sun.util.resources.TimeZoneNames
   1 sun.util.resources.ParallelListResourceBundle$KeySet

通过 jcmd 查看,需要在启动是加上参数:-XX:+UnlockDiagnosticVMOptions

然后我们再看下 JVM 类加载器的数据

jmap -clstats pid

这里 classes 是加载类的数量,从输出中可以看到有大量 GroovyClassLoader 类加载器。

class_loader    classes bytes   parent_loader   alive?  type
<bootstrap>     2850    4913169   null          live    <internal>
0x000000077bc27bc0      1       1394    0x000000077bc64418      dead    groovy/lang/GroovyClassLoader$InnerLoader@0x00000007f0dcf828
0x000000077d9e7d98      0       0       0x0000000770800000      dead    groovy/lang/GroovyClassLoader@0x00000007f0af9890
0x00000007805e8050      0       0       0x0000000770800000      dead    groovy/lang/GroovyClassLoader@0x00000007f0af9890
0x000000077df07de0      0       0       0x0000000770800000      dead    groovy/lang/GroovyClassLoader@0x00000007f0af9890
0x0000000780028010      1       1394    0x000000078005a6c8      dead    groovy/lang/GroovyClassLoader$InnerLoader@0x00000007f0dcf828
0x0000000776467650      1       1394    0x000000077646b190      dead    groovy/lang/GroovyClassLoader$InnerLoader@0x00000007f0dcf828
0x000000077a167a00      1       1394    0x000000077a16b380      dead    groovy/lang/GroovyClassLoader$InnerLoader@0x00000007f0dcf828

通过统计,每个 GroovyClassLoader$InnerLoader 都只加载一个类,然后他的数量一共有 27348,跟上面的 Script1 类数量刚好对的上,说明就是这个类加载器加载的。

接下来怎么定位哪里生产的类加载器加载的类呢?

首先看 groovy 是哪里引入的,然后本地调试,加上JVM 参数:-XX:+UnlockDiagnosticVMOptions,加载类的时候控制台就会打印,就可以一步一步定位到哪里加载的。

我们项目中用 sharding 做的分表,sharding 引入的 groovy 版本如下

<dependency>
    <groupId>io.shardingsphere</groupId>
    <artifactId>sharding-jdbc-spring-boot-starter</artifactId>
    <version>3.0.0.M1</version>
</dependency>
<dependency>
  <groupId>org.codehaus.groovy</groupId>
  <artifactId>groovy</artifactId>
  <classifier>indy</classifier>
  <version>2.4.5</version>
</dependency>

最终定位到出现问题的代码如下,当你配置分表的表达式后,每次执行查询操作,都会创建一个 GroovyShell 来执行配置的表达式。在 GroovyShell 中,每次都会生成一个类加载器,来加载类 Script1,加载完后又无法被 GC 掉,导致内存泄露。

public InlineShardingStrategy(final InlineShardingStrategyConfiguration inlineShardingStrategyConfig) {
    Preconditions.checkNotNull(inlineShardingStrategyConfig.getShardingColumn(), "Sharding column cannot be null.");
    Preconditions.checkNotNull(inlineShardingStrategyConfig.getAlgorithmExpression(), "Sharding algorithm expression cannot be null.");
    shardingColumn = inlineShardingStrategyConfig.getShardingColumn();
    String algorithmExpression = InlineExpressionParser.handlePlaceHolder(inlineShardingStrategyConfig.getAlgorithmExpression().trim());
    closure = (Closure) new GroovyShell().evaluate(Joiner.on("").join("{it -> \"", algorithmExpression, "\"}"));
}

这里升级 sharding 新版本即可,新版本中 GroovyShell 是static 的。

public final class InlineExpressionParser {
...
    private static final GroovyShell SHELL = new GroovyShell();
...
}

这里还有个疑问,类加载器加载用完了并且状态是 dead 为什么不回收掉呢?

本地复现

复现的代码很简单,引入上述 groovy 版本,在运行时加上 JVM 参数

// -Xmx100M -Xms100M -verbose:class -XX:+PrintGCDetails -XX:MaxMetaspaceSize=30M -XX:MetaspaceSize=30M -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UnlockDiagnosticVMOptions -XX:+HeapDumpOnOutOfMemoryError
public static void main(String[] args) {
    for (int i = 0; i < 4000; i++) {
        new GroovyShell().parse("");
    }
}

接下来主要讲下,怎么用 mat 来排查这个类加载为什么没有被回收。用 mat 加载上示例程序 dump 出来的堆,选择 Histogram ,然后在正则中输入 GroovyClassLoader ,Objects 是表示创建对象数量,这里有 3255 个,说明上面的 for 循环执行了 3255 次之后 Metaspace 就溢出了。

image.png

接下来选择 Dominator Tree,然后输入 Script1 正则过滤,右键选择:Path To Gc Roots,这里我们只关心强引用,所以 execlude 其他类型引用。

image.png

如果类加载器被回收,它所加载的类也会被回收,如果类有被引用,肯定不能被回收,所以,我们从 Script1 的对象开始。如下图所有,Script1 类有被引用,最终到达 GC root (AppClassLoader),所以 Full GC 也没法回收掉。

image.png

请先登录,再评论

我用你的代码,复现为什么dead的classloader不能被回收,并不能复现。我把堆设置成100M的时候,太小了,一直FullGC,把堆设置成1024,把metaspace设置成128m,一直能正常回收。所以我认为dead的classloader肯定是能回收的,只是没能触发,因为我也遇到了类似的问题,才查到你这篇文章,能不能帮忙看一下
https://stackoverflow.com/questions/67133935/jvm-full-gc-cant-unload-classes-even-permgen-is-full

1年前

在使用开源代码的时候,对调用的方法得做详细的调研,要做到心中有数。

1年前
1年前回复

shardingJdbc这个bug有点恶心,要运行比较长一段时间才突然full gc

1年前
回复 Thompson:

对如果发版周期比较短的话还不一定能发现

1年前回复

为你推荐

从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
字符串字面量长度是有限制的
前言 偶然在一次单元测试中写了一个非常长的字符串字面量。 正文 在一次单元测试中,我写了一个很长的字符串字面量,大概10万个字符左右,编译时,编译器给出了异常告警 `java: constant
多次字符串相加一定要用StringBuilder而不用-吗?
今天在写一个读取Java class File并进行分析的Demo时,偶然发现了下面这个场景(基于oracle jdk 1.8.0_144): ``` package test; public c
如何通过反射获得方法的真实参数名(以及扩展研究)
前段时间,在做一个小的工程时,遇到了需要通过反射获得方法真实参数名的场景,在这里我遇到了一些小小的问题,后来在部门老大的指导下,我解决了这个问题。通过解决这个问题,附带着我了解到了很多新的知识,我觉得
高吞吐、低延迟 Java 应用的 GC 优化实践
本篇原文作者是 LinkedIn 的 Swapnil Ghike,这篇文章讲述了 LinkedIn 的 Feed 产品的 GC 优化过程,虽然文章写作于 April 8, 2014,但其中的很多内容和
JVM 源码解读之 CMS 何时会进行 Full GC
前言 本文内容是基于 JDK 8在文章[ JVM 源码解读之 CMS GC 触发条件](https://heapdump.cn/article/190389) 中分析了 CMS GC 触发的
「每日五分钟,玩转 JVM」:久识你名,初居我心
聊聊 JVMJVM,一个熟悉又陌生的名词,从认识Java的第一天起,我们就会听到这个名字,在参加工作的前一两年,面试的时候还会经常被问到JDK,JRE,JVM这三者的区别。JVM可以说和我们是老朋友了
据说99.99%的人都会答错的类加载的问题
概述首先还是把问题抛给大家,这个问题也是我厂同学在做一个性能分析产品的时候碰到的一个问题。 同一个类加载器对象是否可以加载同一个类文件多次并且得到多个Class对象而都可以被java层使用吗请仔细注意