分类： java

• 查看 JVM 的内存使用情况
• 分析 MetaSpace OOM 原因
• 快速止血
• 代码分析
• 总结

开发中，将代码部署到 test 环境测试的时候，容器经常因为 OOM 重启，而相同的代部署在 prod 环境则没有问题，怀疑是因为近期 test 环境更换了热部署基础镜像包导致的(由于我们的服务只能在 test 环境进行测试，因此使用了公司的代码修改热部署插件)。于是想通过一些 JVM 工具排查下 OOM 原因，最终发现了历史代码中存在的 bug，同时新的热部署基础镜像包放大了这种影响，导致 metaspace 内存泄漏，排查过程如下：

查看 JVM 的内存使用情况

观察JVM的内存使用情况，主要用了 Arthas 的 dashboard 命令和jdk自带的 jstat 工具。首先，查看 arthas 的 dashboard 数据面板的 Memory 区域，发现 metaspace 区内存使用率一致在增加，直到超过 MaxMetaspaceSize 设置的值，发生 metaspace 的OOM。

观察JVM的内存使用情况

进一步，通过jdk的 jstat 工具查看gc情况，上一次gc是因为 metaspace 内存占用超过了gc 阈值，同时 metaspace 的使用率一直在90%以上，更加验证了 metaspace OOM：

观察JVM的内存使用情况

分析 MetaSpace OOM 原因

JDK8 之后，metaspace 对应于java运行时数据区的 方法区 ，用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据，采用本地内存(Native Memory)来实现 方法区 ，本身没有大小限制(受物理内存大小限制)，但可以使用 -XX:MaxMetaspaceSize 参数设置上限，我们这边设置的是2G。

既然是因为类的元数据信息撑爆了元空间，那就看一下类的装载和卸载情况吧，使用 jstat 工具看下类加载情况，并对比 test 和 prod 两个环境的差异：

「test」

分析 MetaSpace OOM 原因

「prod」

分析 MetaSpace OOM 原因

prod 环境的服务加载了很多类也卸载了很多类(这其实是个线上问题，通过这次排查才发现的，后面分析原因)，而 test 更加严重，加载了很多类，但几乎没有卸载过类。

重点看下 test 服务的类加载情况，使用 Arthas 的 classloader 命令：

分析 MetaSpace OOM 原因

第一眼就觉得 AviatorClassLoader 比较可疑，其他加载器都是spring和jdk的，这个是谷歌的，同时这个类加载器的实例数量和加载的类的数量非常大，同时随着服务的运行在不断的增长。仅仅是类加载器的实例数量大倒还好，毕竟它的 Class 对象就一份，不会撑爆元空间，但它加载的 Class 会有问题，因为判断是不是同一个类，是由 「加载它的类加载器+全限定类名」 一起决定，于是乎，可以从这个类加载器入手，代码中全局搜索一下，果然找到了引入点。

快速止血

我们的项目是接手的一个报表类的服务，项目中用到了一个表达式计算引擎 AviatorEvaluator ，用来根据表达式字符串计算复合指标，其伪代码如下表示：

public static synchronized Object process(Map eleMap, String expression) {
    // 表达式引擎实例
    AviatorEvaluatorInstance instance = AviatorEvaluator.newInstance();
    // 生产表达式对象
    Expression compiledExp = instance.compile(expression, true);
    // 计算表达式结果
    return compiledExp.execute(eleMap);
}

其中 expression 是表达式字符串，eleMap 是表达式中变量名和具体值的键值对，比如 expression 对应 a+b ，eleMap对应的键值对为 {"a":10, "b":20} ，则process方法的结果为30。

之前从未仔细看过这段代码，现在看下来似乎有点不太对劲：synchronized 和 newInstance 是重复了吗？synchronized 是用来做同步的，说明这段代码中有共享资源竞争的情况，应该就是 AviatorEvaluator 实例了，目前的逻辑每次执行 process 都会实例化一个 AviatorEvaluator 对象，这已经不仅仅是线程私有了，而是每一个线程每次调用这个方法都会实例化一个对象，已经属于 「线程封闭」 的场景了，不需要用 synchronized 关键字做同步。我们的业务场景对这个方法的调用量非常大，每个指标的计算都会调用这个方法。至此，有以下结论：

1. synchronized 同步和线程封闭每个线程私有一个对象二者选其一就行；
2. 如果 AviatorEvaluator 是线程安全的话，使用单例模式就行，可以减轻堆区的内存压力；

谷歌出品的工具类不是线程安全的？不会吧？

查阅资料得知，AviatorEvaluator 的 execute 方法是线程安全的，代码里的使用姿势不对，修改代码如下，重新发布，不再OOM了。

// 删除 synchronized
public static Object process(Map eleMap, String expression) {
   AviatorEvaluator.execute(expression, eleMap, true); // true 表示使用缓存
}

代码分析

但是，还是有两点难以解释：a) 为什么是 metaspace ？b) 为什么使用热部署镜像的 test 环境出现 OOM，而 prod 没有出现 OOM？

如果是因为 AviatorEvaluator 对象太多导致的，那也应该是堆区 OOM；同时，prod 环境的请求量远大于 test 环境，如果是像目前 test 这种 metaspace 的膨胀速度，线上肯定也是会 OOM 的，差异在于 test 用的热部署的基础镜像包。

「首先探寻第一个问题的答案，为什么是 metaspace ？」

热部署？ClassLoader? 方法区？此时，脑海里回想起一道经典八股文：动态代理的两种方式？(JDK动态代理和CGLIB动态代理的区别？AOP的实现原理？运行期、类加载期的字节码增强？)

感觉这次 OOM 很大可能是 ** 「ClassLoader」 和 ** 「热部署(字节码增强)」** 撞出的火花 …**

通过阅读 AviatorEvaluator 的源码，发现调用链简化后大概是这样：

public Object execute(final String expression, final Map env, final boolean cached) {
  Expression compiledExpression = compile(expression, expression, cached); // 编译生成 Expression 对象
  return compiledExpression.execute(env);  // 执行表达式，输出结果
}
private Expression compile(final String cacheKey, final String exp, final String source, final boolean cached) {
 return innerCompile(expression, sourceFile, cached);  // 编译生成 Expression 对象
}
private Expression innerCompile(final String expression, final String sourceFile, final boolean cached) {
  ExpressionLexer lexer = new ExpressionLexer(this, expression);
  CodeGenerator codeGenerator = newCodeGenerator(sourceFile, cached); //!!这个方法 new AviatorClassLoader 的实例
  return new ExpressionParser(this, lexer, codeGenerator).parse(); 
}
  public CodeGenerator newCodeGenerator(final String sourceFile, final boolean cached) {
    // 每个 AviatorEvaluatorInstance 一个 AviatorClassLoader 的实例作为成员变量
    AviatorClassLoader classLoader = this.aviatorClassLoader;
    //!!这个方法通过上面的类加载器不断生成并加载新的Class对象
    return newCodeGenerator(classLoader, sourceFile);
  }
public CodeGenerator newCodeGenerator(final AviatorClassLoader classLoader, final String sourceFile) {
 ASMCodeGenerator asmCodeGenerator = 
    // 使用字节码工具ASM生成内部类
    new ASMCodeGenerator(this, sourceFile, classLoader, this.traceOutputStream);
}
public ASMCodeGenerator(final AviatorEvaluatorInstance instance, final String sourceFile,
    final AviatorClassLoader classLoader, final OutputStream traceOut) {
  // 生成了唯一的内部类
  this.className = "Script_" + System.currentTimeMillis() + "_" + CLASS_COUNTER.getAndIncrement();
}

这时候原因差不多清晰了，使用 AviatorEvaluatorInstance 对象计算表达式会使用成员变量里的一个 AviatorClassLoader 加载自定义的字节码生成 CodeGenerator 对象。AviatorEvaluatorInstance 用单例模式使用固然没什么问题，但是如果每次都 new 一个AviatorEvaluatorInstance 对象的话，就会有成百上千的 AviatorClassLoader 对象，这也解释了上面通过 Arthas 查看 classloader 会有这么多对应的实例，但 metaspce 的 Class 还是只有一份的，问题不大。同时看到生成的字节码对象都是 Script_ 开头的，使用 arthas 的 sc 命令看下满足条件的类(数量非常多，只截取了部分)，果然找到了 OOM 的元凶：

OOM 的元凶

「第二个疑问：为什么 prod 没有OOM？」

上面通过 jstat 发现 prod 卸载了很多类，而 test 几乎不卸载类，两个环境唯一的区别是 test 用了热部署的基础镜像。

咨询了负责热部署的同事，了解到热部署 agent 会对 classloader 有一些 强引用，监听 classloader 的加载的一些类来监听热更新，这会导致内存泄漏的问题。同时得到反馈，热部署后面会用 弱引用 优化。这里引用下《深入理解java虚拟机》中的解释：

弱引用优化

因为大量的 AviatorEvaluatorInstance 创建了大量的 AviatorClassLoader ，并被热部署 agent 强引用了，得不到回收，那么这些类加载器加载的 Script_* 的Class对象也得不到卸载，直到 metaspace OOM。

通过 JVM 参数 -Xlog:class+load=info 、-Xlog:class+unload=info 看下 prod 环境的类加载和类卸载日志，确实有大量 Script_* 类的加载和卸载:

类的加载和卸载

类的加载和卸载

而 test 环境这没有此种类的卸载，这边就不再贴图了。

此刻，我比较好奇的是热部署包里的什么类型的对象强引用了我们的自定义类加载器？使用 jprofiler 看下两个环境的堆转储文件，不看不知道，一看吓一跳，问题比想象的更加严重：

「prod」

堆转储文件

「test」

堆转储文件

对比 prod 和 test 环境的引用情况，test 环境存在热更新类 WatchHandler 对象到 AviatorClassLoader 的强引用，而 prod 环境不存在；进一步，选择一个具体的 AviatorClassLoader 实例看下引用情况，又有了重大发现：

「prod」

AviatorClassLoader

「test」

AviatorClassLoader

prod 环境的 AviatorClassLoader 除了加载我们业务需要的自定义类 Script_*，还加载了很多热更新相关的类，同时不同 AviatorClassLoader 实例加载的热更新相关的类的 hashcode 也是不同了，说明每个 AviatorClassLoader 实例都加载了一轮，这才是元空间占用内存的大头。

当然，在正确使用 AviatorEvaluator 的情况下(使用单例模式)，就不会出现这么严重的问题了，但依然存在热部署 agent 对自定义 classloader 的强引用问题。

总结

这是我第一次系统地排查 OOM 问题，把之前一些零散模糊的知识点给串起来的，下面总结了一些本次排查涉及到的 JVM 基础概念和工具：

「元空间：」

• https://segmentfault.com/a/1190000012577387

「类加载器：」

• https://segmentfault.com/a/1190000037574626
• https://segmentfault.com/a/1190000023666707

「JDK工具：」

• jps：JVM Process Status Tool 进程状况工具
• jstat：JVM Statistics M onitoring Tool 统计信息监视工具
• jinfo：Configuration Info for Java Java配置信息工具
• jmap：Memory Map for Java 内存映像工具
• jhat：JVM Heap Analysis Tool 堆转储快照分析工具
• jstack：Stack Trace for Java 堆栈跟踪工具
• Jcmd：多功能诊断命令行工具

前言

easy-jenkins是一款对vue和jar的部署工具，操作简单，实行一键部署，内部结构采用流水线形式架构，每次部署，时时提供部署过程，部署记录，界面友好简洁，使用方便，符合用户常规操作

easy-jenkins面向分支形式，无需登录，默认分支为jenkins，每个分支可以配置多个数据源，切换不同分支可以管理不同数据源

easy-jenkins采用本地存储的结构无需配置数据库，简单易上手

提示：以下是本篇文章正文内容，下面案例可供参考

一、项目地址

开源地址：

• https://gitee.com/susantyp/easy-jenkins

二、使用步骤

先把代码拉入你的本地

1.项目结构

2.启动主类 EasyJenkinsApplication

3.安装

启动后弹出当前窗体 点击下一步

来到这里后，填写相应的信息

• 安装路径
• maven路径 打包需要
• 以及项目端口的启动，避免不要和本地端口冲突，我们可以设置 8332 8899 9900 等端口

点击安装并启动， 点击确认 等待几秒，项目自动启动

4.项目启动图

三、功能点介绍

• 部署列表
• 部署记录
• 数据分支
• 基本设置

1.部署列表

部署列表主要显示我们的连接信息

1.添加连接（部署jar）

我们点击按钮，添加连接

添加本地项目地址

添加本地项目地址后，它下面的文本款会根据本地项目地址自动生成，如图

在这边需要确保：

• 你的本地项目地址是正确的
• jar名称正确的
• pom.xml文件是正确的

我部署项目的端口为8080

根据你自己的项目设置端口

添加服务器相关信息

在我们的右边填写我们的服务器信息

• 服务器ip
• 账号
• 密码
• 端口

上传的位置 后面不需要带 /

上传的位置 默认生成一个命令

如果上传位置是 /home/springboot

则生成如下

nohup java -jar /home/springboot/wall.jar & tailf /home/springboot/nohup.out

可以修改为你自己需要运行的命令

或者直接使用当前命令

2.部署jar

我们点击部署按钮即可

后台会实时返回部署的消息，返回给前端显示

3.部署成功

部署成功返回：Successfully deployed

4.删除

点击table 直接删除

5.编辑

编辑小伙伴可以自己玩一下

2.部署记录

部署记录主要记录了，最近部署的情况和统计信息

3.数据分支

easy-jenkins 是面向分支的

不同分支存储不同的连接，默认分支为jenkins

1.创建分支

创建一个root的分支

2.切换分支

切换完成后，可以查看当前分支的状态

当前我们就是root分支的环境下

我们点击部署记录

部署记录此时为空的，刚刚创建分支下面是没有连接数据的，需要重新添加连接

我们切换为jenkins分支后，前面我们在jenkins添加了一条连接数据，下面就显示数据了，同时上面会标注当前的环境为jenkins

注意了，正在使用的分支是不可以删除

4.基本设置

• 安装路径
• maven路径
• 项目端口号

当前这三个值，是我们最初刚刚开始安装的时候的需要录入的值，我们可以点击编辑操作

5.启动

• 第一次启动会启动安装向导程序
• 第二次启动直接启动浏览器，则不再启动安装向导程序

6.如何部署vue

dist 是vue项目默认build的位置

同样 后面 不需要 ‘/’

需要注意

上传位置名字保持跟本地相同的名字，如图：

然后填写你相应的服务器信息即可

7.exe启动项目

在我们exe文件夹下面，有一个easy-jenkins.exe文件

可以将他拷贝到桌面，直接点击它运行即可，不需要每次启动springboot程序

总结

此部署工具主要针对于个人本地的部署

针对于小型项目的部署，轻量级的，一键部署，操作简单

前言

首先说结论：无论什么场景，都不要对List使用for循环的同时，删除List集合元素，因为这么做就是不对的。

阿里开发手册也明确说明禁止使用foreach删除、增加List元素。

正确删除元素的方式是使用迭代器（Iterator），代码如下：

List list = new ArrayList();
Iterator iterator = list.iterator();
while (iterator.hasNext()) {
    // 删除元素
    iterator.remove();
}

JDK8后lambda写法：list.removeIf(s -> s.contains("a"));

不想知道为什么不能使用for循环删除List集合元素的，看完前言就可以关闭本页面了，想知道原因的继续往下看

实例

下面举个实例场景，看一下为什么不能使用for循环。

需求

一个List集合，元素类型为String，有N个元素，删除这些元素中包含字符”a”的元素。

假设集合内容如下：

List list = new ArrayList(4);
list.add("a");
list.add("ab");
list.add("abc");
list.add("abcd");

正确答案

先上正确答案

public static void main(String[] args) {
    List list = new ArrayList(4);
    list.add("a");
    list.add("ab");
    list.add("abc");
    list.add("abcd");

    Iterator iterator = list.iterator();
    while (iterator.hasNext()) {
        if (iterator.next().contains("a")) {
            // 删除元素
            iterator.remove();
        }
    }
    System.out.println(list);
}

输出结果为

[]

错误答案1：普通for循环（for-i）

public static void main(String[] args) {
    List list = new ArrayList(4);
    list.add("a");
    list.add("ab");
    list.add("abc");
    list.add("abcd");

    for (int i = 0; i         if (list.get(i).contains("a")) {
            list.remove(i);
        }
    }
    System.out.println(list);
}

输出结果为

[ab, abcd]

分析

普通for循环遍历List集合的同时，删除List中的元素是可以运行的代码，但在大多数场景下，不能使用这种方式，上边的结果也印证了这一点，虽然你的代码不会报错，运行也正常，但在本实例中，这么写就是BUG。

BUG原因：索引为i的元素删除后，后边元素的索引自动向前补位，即原来索引为i+1的元素，变为了索引为i的元素，但是下一次循环取的索引是i+1，此时你以为取到的是原来索引为i+1的元素，其实取到是原来索引为i+2的元素。

如下图示例：

看图可以发现，只要每删除一个元素，就会漏掉下一个元素，所以这种方式从逻辑上来说是存在bug的，无论什么需求场景，都不建议用这种方式，因为不可控因素太多（鬼知道生产环境中他会删掉多少元素，同时漏掉多少元素）。

既然这么写不报错，那么个别特殊场景确实可以使用这种普通for循环删除元素的，比如我们把实例的需求变动一下，改为：一个List集合，元素类型为String，有N个元素，删除这些元素中包含字符’a’的元素，如果有连续两个或以上元素包含’a’，那么只删除当前连续元素中的奇数位元素。虽然这种场景适用，但仍然不推荐，还是因为太不可控。

错误答案2：增强for循环（foreach）

public static void main(String[] args) {
    List list = new ArrayList(4);
    list.add("a");
    list.add("ab");
    list.add("abc");
    list.add("abcd");

    for (String str : list) {
        if (str.contains("a")) {
            list.remove(str);
        }
    }
    System.out.println(list);
}

运行报错：

Exception in thread "main" java.util.ConcurrentModificationException
 at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909)
 at java.util.ArrayList$Itr.next(ArrayList.java:859)
 at top.oldmoon.learn.test.ListTest.main(ListTest.java:24)

使用百度翻译可以知道：Concurrent Modification Exception：并发修改异常

分析

其实这里没啥好分析的，直接报错了，你还这么写干嘛？没事找罪受吗。。。

可以简单的理解为：foreach就不支持对集合中的元素进行增删操作，但是可以修改。