hprof 文件分析
2021-08-24,订单中心的一个项目出现了 OOM 异常,使用 MemoryAnalyzer 打开 dump 出来的 hprof 文件,可以看到 91.27% 的内存被一个超大对象javassist.ClassPool占用了。
那么,ClassPool是一个什么样的对象呢?我们知道,javassist 可以用来动态生成类,而生成的类就是放在这个ClassPool里面,具体以javassist.CtClass的形式存在。
所以,初步分析是 OOM 的原因是 javassist 生成的CtClass对象过多,即 javassist 生成了太多的类。
为了验证我的猜想,我需要看看CtClass对象的内存情况,点击 Actions -> Histogram,如图。果然,这 2.3 G 的内存就是CtClass对象占用的。
接下来,我需要知道这些CtClass对象都是哪些类,点击 List objects -> with outgoing references。这时可以看到,项目里生成了大量的Orika_ProductionOrderUpdateCmd_ProductionOrderE_Mapper*。
看着这些类的命名规则,是不是很熟悉呢?它们都是 orika 映射 bean 时动态生成的类。所以,大量的CtClass对象是由 orika 产生。orika 的原理我之前讲过(cglib、orika、spring等bean copy工具性能测试和原理分析),这里就不再赘述。
但是,orika 生成的映射类是可以复用的,为什么还会有这么多重复的映射类呢?
项目代码分析
在项目中找到唯一一处将ProductionOrderE映射成ProductionOrderUpdateCmd的地方。
在项目中,其他地方都是使用方法 1,唯独这里使用了方法 2,所以,有理由怀疑是不是方法 2 有 bug 呢?
public class BeanUtils { // 方法1 public static <S, D> D copy(S source, Class<D> destinationClass) { // ······ } // 方法2 public static <S, D> D copy(S source, Class<D> destinationClass, String excludeFields) { // ······ }}
于是,我写了个简单的 demo,如下。我的假设是,使用方法 2 不会复用映射类,每 copy 一次就生成一个映射类,最终导致映射类过多。至于生成了几个映射类,我们可以通过输出映射类文件的方式来判断,使用启动参数-Dma.glasnost.orika.GeneratedSourceCode.writeSourceFiles=true -Dma.glasnost.orika.writeSourceFilesToPath=D:/tmp/orika可以输出映射类文件。
public static void main(String[] args) { ProductionOrderE productionOrder = new ProductionOrderE(); // 使用方法2 ProductionOrderUpdateCmd copy = BeanUtils.copy(productionOrder, ProductionOrderUpdateCmd.class, "belongShop,belongOrg,userOperate,orgExtendInfo"); ProductionOrderUpdateCmd copy2 = BeanUtils.copy(productionOrder, ProductionOrderUpdateCmd.class, "belongShop,belongOrg,userOperate,orgExtendInfo"); // 使用方法1 // ProductionOrderUpdateCmd copy3 = BeanUtils.copy(productionOrder, ProductionOrderUpdateCmd.class); // ProductionOrderUpdateCmd copy4 = BeanUtils.copy(productionOrder, ProductionOrderUpdateCmd.class); // zzs001 }
运行方法,我们会发现,使用方法 1 时,只生成了一个映射类,而使用方法 2 时,生成了两个映射类。
以下是方法 2 的底层封装,这里使用ClassMapBuilder重新配置了ProductionOrderUpdateCmd和ProductionOrderE的映射关系,导致上一次 copy 时生成的CtNewClass对象不再复用。
所以,在使用 orika 时,A->B 的映射关系只能定义一次,不能反复定义。
private MapperFactory mapperFactory; public <S, D> D copy(S source, Type<S> from, Type<D> to, String excludeFields) { List<String> list = new ArrayList<>(); if(excludeFields != null) { list = Arrays.asList(excludeFields.split(",")); } ClassMapBuilder cb = this.mapperFactory.classMap(from, to); for(String s : list) { cb.exclude(s.trim()); } cb.byDefault().register(); return this.mapperFactory.getMapperFacade().map(source, from, to); // zzs001 }
解决方案
经过上面的分析,解决方案就呼之欲出了,我们只需要在初始化时一次定义好ProductionOrderUpdateCmd和ProductionOrderE的映射关系就行了,如下。当然,方法 2 不能再用了。
public class BeanUtils { static { ClassMapBuilder cb = BeanToolkit.instance().getMapperFactory().classMap( TypeFactory.valueOf(ProductionOrderE.class), TypeFactory.valueOf(ProductionOrderUpdateCmd.class) ); cb.exclude("belongShop"); cb.exclude("belongOrg"); cb.exclude("userOperate"); cb.exclude("orgExtendInfo"); cb.byDefault().register(); // zzs001 }}
结语
经过以上分析,我们找到了 OOM 的原因,并较好地解决了问题。其实,我们应该更早的监控到异常,像上面说的这种会出现非堆内存过高的情况。
最后,感谢阅读,欢迎私信交流。
本文为原创文章,转载请附上原文出处链接:https://www.cnblogs.com/ZhangZiSheng001/p/15184914.html