Orika框架封装问题排查

最新推荐文章于 2024-02-01 14:30:49 发布

slagsea

最新推荐文章于 2024-02-01 14:30:49 发布

阅读量2.2k

点赞数

文章标签： jvm orika

本文链接：https://blog.csdn.net/qq_34147021/article/details/116905184

版权

博客讲述了在使用Orika框架进行Bean映射时遇到的性能问题，通过排查发现由于封装的Orika工具类导致的缓存穿透，使得DefaultMapperFactory.registerClassMap方法的synchronized锁引起线程阻塞。此外，JVM的年轻代频繁GC及元数据增长也加剧了问题，最终导致接口响应越来越慢。解决方案涉及优化Orika工具类的缓存策略和调整JVM内存配置。

摘要由CSDN通过智能技术生成

背景

个人维护的一个后台服务使用了Orika框架去处理bean对象之间的映射，并对Orika框架做了简单的封装，减少冗余代码。这里简单说明下Orika框架的原理，Orika框架是在运行时动态创建字节码，生成最小开销的映射器来实现Bean对象之间映射的。其他Bean映射的框架有Mapstruct、BeanCopier等。

问题

后台服务在内部测试环境运行一段时间后，突然发现部分接口响应很慢，而且接口越刷越慢，平均接口耗时十几秒,造成前端接口响应超时，刷不出数据。

问题排查

初步排查

针对相关接口业务逻辑做初步排查后，怀疑耗时主要Orika的bean映射过程。是Orika框架有bug？还是封装的Orika工具类有隐藏的问题？

深入排查

1）封装的Orika工具类处理Bean映射时耗时突然变长，可能有线程阻塞。

本地启动服务，使用jmeter去本地测试验证，每秒100线程请求并发，循环5次。借助arthas工具，使用thread -b 命令查看当前服务是否有阻塞的线程。

jmeter

Orika阻塞

经过测试，确实存在阻塞的线程，由Orika的DefaultMapperFactory.registerClassMap方法引起了线程阻塞。

2）分析DefaultMapperFactory.registerClassMap源码

这块代码是Orika生成映射器的主要逻辑，方法代码块加了synchronized 重量级锁。

public synchronized <A, B> void registerClassMap(ClassMap<A, B> classMap) {
        this.classMapRegistry.put(new MapperKey(classMap.getAType(), classMap.getBType()), classMap);
        //判断映射器是否正在构建中或者是否已经构建过，若是则重新构建注册
        if (this.isBuilding || this.isBuilt) {
            MappingContext context = this.contextFactory.getContext();
            try {
                if (classMap.getUsedMappers().isEmpty()) {
                    classMap = classMap.copyWithUsedMappers(this.discoverUsedMappers(classMap));
                }
                this.buildMapper(classMap, this.isBuilding, context);
                this.buildObjectFactories(classMap, context);
                this.initializeUsedMappers(classMap);
                this.mapperFacade.factoryModified(this);
            } finally {
                //释放缓存中映射bean的类型、类属性等信息
                this.contextFactory.release(context);
            }
        }
    }

这里简单说下synchronized锁，锁的原理是基于Java 对象头和 Monitor实现的。

当多个线程同时请求资源临界区时，对象监视器会设置几种状态用来区分请求的线程，涉及线程状态流转可以简单理解下图：

Synchronize

通过线程状态流转可以看出使用了synchronized锁，在并发情况下会有锁等待，这个锁的效率比较低。

由此可以分析，确实因为DefaultMapperFactory.registerClassMap方法阻塞引起的耗时。

但是为什么会不断走到这个动态生成映射器的方法呢？有可能是封装的Orika工具类导致的问题。

3）封装的MapperUtil工具类分析

封装的工具类封装了Orika的基础操作，并缓存了Orika的mapperFacade。

工具类完整代码地址：https://gitee.com/LuXianShengTeam/orika-test/blob/master/src/main/java/com/orika/test/util/MapperUtil.kt

经过分析，是代码在特殊情况下本地缓存穿透，不断执行classMapBuilder.byDefault().register() 去注册映射器。核心代码如下：

/**
     * 获取自定义映射
     *
     * @param toClass 映射类
     * @param dataClass 数据映射类
     * @param targetPropertyMap 处理字段名称不一致 (key 原对象属性 value 目标对象属性)
     * @return 映射类对象
     */
    private fun <E, T> getMapperFacade(
            toClass: Class<E>,
            dataClass: Class<T>,
            targetPropertyMap: Map<String, String> = emptyMap(),
            excludes: List<String> = emptyList(),
            converterMap: Map<String, String> = emptyMap()
    ): MapperFacade {
        val mapKey = dataClass.canonicalName + "_" + toClass.canonicalName
        var mapperFacade = CACHE_MAPPER_FACADE_MAP[mapKey]
        //此处缓存穿透
        if (mapperFacade != null && excludes.isEmpty() && converterMap.isEmpty()) {
            return mapperFacade
        }

        //排除属性
        var classMapBuilder = MAPPER_FACTORY.classMap(dataClass, toClass)
        excludes.forEach {
            classMapBuilder = classMapBuilder.exclude(it)
        }

        //属性映射
        targetPropertyMap.forEach {
            val converterId = converterMap[it.key]
            if (converterId != null) {
                classMapBuilder.fieldMap(it.key, it.value).converter(converterId).add()
            } else {
                classMapBuilder.field(it.key, it.value)
            }
        }

        classMapBuilder.byDefault().register()
        mapperFacade = MAPPER_FACTORY.mapperFacade
        CACHE_MAPPER_FACADE_MAP[mapKey] = mapperFacade
        return mapperFacade
    }

问题的主要是原因找到了，可是还存在一个问题，为什么接口会越刷越慢？如果不断注册生成映射器平均耗时是相近的话，应该不会出现很多线程处理在队列排队情况。可以注意到Orika是不断动态生成class加载进jvm，是不是jvm引起的呢？