又一个beanCopy引发的血案metaspace溢出

项目频繁发生metaspace溢出，基于相关知识毫不犹豫的想到以下几点

项目中使用过多反射
项目中使用过多的动态代理技术
项目中使用过多的lambda

项目启动完成后，框架层面很多东西固定了，运行期间最有可能引起问题的地方无疑是我们大量的使用了beanCopy那么检查项目发现各种方式的beanCopy都有，有apache的BeanUtils，有spring的BeanUtils，有cglib的BeanCopy。并且我们的很多实体都有上百个字段。
于是构建相关案例如下：
先来对比下spring 中提供的两种beancopy的方式对metaspace的使用情况

package com.qimo.omsa.demo.metaspace;import java.util.concurrent.TimeUnit;
import org.springframework.beans.BeanUtils;
import org.springframework.cglib.beans.BeanCopier;/*** @Description TODO* @Author 姚仲杰#80998699* @Date 2022/3/18 13:45*/
public class MetaspaceTest {public static void main(String[] args) throws Exception {int i=1;
//        while(true) {//            TimeUnit.SECONDS.sleep(3);
//            reflect();
//            System.out.println(i);
//            i++;
//        }while(true) {TimeUnit.SECONDS.sleep(3);cglib();System.out.println(i);i++;}}public static void reflect() {Product product=new Product();ProductVO productVO = new ProductVO();BeanUtils.copyProperties(product,productVO);}public static void cglib(){Product product = new Product();ProductVO productVO = new ProductVO();BeanCopier beanCopier = BeanCopier.create(Product.class, ProductVO.class, false);beanCopier.copy(product,productVO,null);}}

第一种 BeanUtils.copyProperties，这种方式使用的是反射的方式进行调用我们使用jcmd 命令查看下metaspace的使用情况发现前15次调用情况如下jcmd 23328 VM.classloader_stats

Total = 3                                                     1276   7915520   7636416
ChunkSz: Total size of all allocated metaspace chunks
BlockSz: Total size of all allocated metaspace blocks (each chunk has several blocks)

而在15次之后的情况如下jcmd 23328 VM.classloader_stats

Total = 1035                                                  2321  14387200  10678952
ChunkSz: Total size of all allocated metaspace chunks
BlockSz: Total size of all allocated metaspace blocks (each chunk has several blocks)

可以看到在15次前classloader一直是3个，而15次之后增长到了1035个往后稳定在1035个

先声明下我的product对象的属性是516个，每个属性各有两个方法 getter，setter，productVo也是同样的对象。结合数据我们不难看这1035-3/2刚好是516。也就是说每个方法使用了一个classloader。并且ChunkSz和BlockSz 也是增加了非常多，这个增加意味着metaspace空间被使用了。
那么我们在同样的条件下测试下spring提供的另一个基于cglib的BeanCopy结果如下
前15次调用

Total = 3                                                      805   6180864   5358144
ChunkSz: Total size of all allocated metaspace chunks
BlockSz: Total size of all allocated metaspace blocks (each chunk has several blocks)

15次后调用

Total = 4                                                      820   6187008   5439976
ChunkSz: Total size of all allocated metaspace chunks
BlockSz: Total size of all allocated metaspace blocks (each chunk has several blocks)

我们发现cglib的beanCopy仅仅增加了一个classloader，并且对metaspace的使用增加幅度非常小。

意味着项目中如果大量使用了反射方式的beancopy就会创建大量的DelegatingClassLoader，那么这里为什么是15次之后才出现呢？我们顺着BeanUtils.copyProperties方法点进去找到代码如下：

public MethodAccessor newMethodAccessor(Method var1) {checkInitted();if (noInflation && !ReflectUtil.isVMAnonymousClass(var1.getDeclaringClass())) {return (new MethodAccessorGenerator()).generateMethod(var1.getDeclaringClass(), var1.getName(), var1.getParameterTypes(), var1.getReturnType(), var1.getExceptionTypes(), var1.getModifiers());} else {NativeMethodAccessorImpl var2 = new NativeMethodAccessorImpl(var1);DelegatingMethodAccessorImpl var3 = new DelegatingMethodAccessorImpl(var2);var2.setParent(var3);return var3;}}

我们再来看下如else中的两个MethodAccessor实现
1、NativeMethodAccessorImpl
通过阅读以下代码我们可以知道inflationThreshold这个属性阈值的15，从命名我们可以得知这个实现是通过jni调用native的方式直接读取字节码。但是这里还有个setParent方法，等到inflationThreshold超过15时将字节码获取从jni方式转成DelegatingMethodAccessorImpl 方式。所以接着我们看DelegatingMethodAccessorImpl

class NativeMethodAccessorImpl extends MethodAccessorImpl {private final Method method;private DelegatingMethodAccessorImpl parent;private int numInvocations;NativeMethodAccessorImpl(Method var1) {this.method = var1;}public Object invoke(Object var1, Object[] var2) throws IllegalArgumentException, InvocationTargetException {if (++this.numInvocations > ReflectionFactory.inflationThreshold() && !ReflectUtil.isVMAnonymousClass(this.method.getDeclaringClass())) {MethodAccessorImpl var3 = (MethodAccessorImpl)(new MethodAccessorGenerator()).generateMethod(this.method.getDeclaringClass(), this.method.getName(), this.method.getParameterTypes(), this.method.getReturnType(), this.method.getExceptionTypes(), this.method.getModifiers());this.parent.setDelegate(var3);}return invoke0(this.method, var1, var2);}void setParent(DelegatingMethodAccessorImpl var1) {this.parent = var1;}private static native Object invoke0(Method var0, Object var1, Object[] var2);
}

2、DelegatingMethodAccessorImpl
此方法并没有做什么，只是一个委托。

class DelegatingMethodAccessorImpl extends MethodAccessorImpl {private MethodAccessorImpl delegate;DelegatingMethodAccessorImpl(MethodAccessorImpl var1) {this.setDelegate(var1);}public Object invoke(Object var1, Object[] var2) throws IllegalArgumentException, InvocationTargetException {return this.delegate.invoke(var1, var2);}void setDelegate(MethodAccessorImpl var1) {this.delegate = var1;}
}

所以我们需要回看Native的实现超过15次之后的if语句中的代码

MethodAccessorImpl var3 = (MethodAccessorImpl)(new MethodAccessorGenerator()).generateMethod(this.method.getDeclaringClass(), this.method.getName(), this.method.getParameterTypes(), this.method.getReturnType(), this.method.getExceptionTypes(), this.method.getModifiers());this.parent.setDelegate(var3);

我们点开MethodAccessorGenerator发现它时通过字节码去构建了一个class并调用ClassDefiner.defineClass去加载了该class放到metaspace中。从而使得每个方法在调用15次之后从jni获取字节码的方式转到java层面直接加载来提升性能。我们发现在
newMethodAccessor这个方法里面还用到一个参数noInflation 默认为false也就是如果设置这个参数为true则直接走java层面的的字节码生成并加载。达到提升性能的效果。也就是如果设置这个值为true就不用关心inflationThreshold的值了这里为了提升性能也是煞费苦心了。
以上两个参数可以直接通过-Dsun.reflect.noInflation=true,-Dsun.reflect.inflationThreshold=15jvm传参的方式来设置。所以在使用反射调用method.Invoke()的时候，当你的使用次数超过15次就会为每一个method生成一个class。就会导致metaspace极速膨胀。因此这里这个参数也取名叫noInflation（膨胀）。而在cglib方式下则是以类为单位，所以同样也走到了相关的代码，但是它只生成了一个DelegatingClassLoader，所以它的metaspace内存占用比反射来的小很多。而在反射有缓存的情况下cglib方式还是比反射性能要高一点点。所以此处我们已经很明确这个问题出在项目中大量使用的反射的beancopy导致metaspace溢出，理论上来说这种情况可以通过调大metaspace得以解决，但是更好的解决方案是尽量使用cglib方式的beancopy

又一个beanCopy引发的血案metaspace溢出相关推荐

『转』度百死去飞秋一个BUG引发的血案
作了一篇文章度百死去飞秋一个BUG引发的血案,昨天,度百死去的美国客户发邮件给我,说我的软件出问题了,我查来查去,发现居然是服务器上一个目录无法删除,一删除就报 cannot read from th ...
【Elasticsearch】es 一个数据精度引发的血案
1.概述在看博客的时候,发现有个博客一个数据精度引发的血案上面说,数据精度会丢失,然后我在 7.8.0版本的es测试,发现数据没有丢失. POST /index-lcc-0002/_doc {& ...
”一个馒头引发的血案“|记Mybatis之BindingException异常的产生及解决过程
一. 业务场景前几天壹哥带学生做一个项目,需要更新数据库中的车辆信息表,具体需求是要根据指定车辆的设备id(编号和设备ID均非主键)来更新车辆信息.壹哥要求学生们用Mybatis进行实现,所以就在对 ...
一个馒头引发的血案...请看完无极后观看此片,保笑死人不偿命
一个馒头引发的血案... 采用搞笑的手法拍摄的,笑到你喷饭,极大的讽刺无极下载地址:点击下载
摘要: Druid连接池一个设置引发的血案 -- 链接池出现问题
摘要: Druid连接池一个设置引发的血案今天在一台配置很低的机器上运行批量更新的程序~~~ 大概跑了三十分钟~~~这配置~~~这程序~~~ 然后华丽丽的报异常了~~~ 具体异常是这样的, DEBU ...
一个随机数引发的血案
一个随机数引发的血案我也来做一次标题党原文地址:http://blog.csdn.net/WinsenJiansbomber/article/details/50604653 目录一个随机数引发 ...
线上 CPU100% 异常案例：一个正则表达式引发的血案
前几天线上一个项目监控信息突然报告异常,上到机器上后查看相关资源的使用情况,发现 CPU 利用率将近 100%.通过 Java 自带的线程 Dump 工具,我们导出了出问题的堆栈信息. 我们可以看到所 ...
一个NODE_ENV 引发的血案
1 表象控制台报错截图没有完整的截下来,其实右边行号并没有具体的行号, 显示为payment-809e8ff.js 1 很明显这是 js语法错误但是当点击开里面显示的是html内容第一行的 ...
一个“alert” 引发的血案
0 在还没有掌握全部证据之前就下结论会犯严重的错误,会使判断带有偏见.--<血字的研究> "齐识,路老板又来邮件了."白娜一脸无耐地说. "一定没好事吧?&q ...

又一个beanCopy引发的血案metaspace溢出

又一个beanCopy引发的血案metaspace溢出相关推荐

最新文章

热门文章