记一次JPA项目启动速度优化

本是古典何须时尚 2023-02-28 15:29 31阅读 0赞

### 一、背景 ###

公司项目引入JPA改造了数据层，方便项目适配多种类型数据库，但也逐渐变得臃肿，模块启动速度缓慢。原先web模块启动一次大概需要14s，而改造后启动一次大概需要44s，不便于项目的开发、调试和部署。

### 二、猜测 ###

网上查了一下关于项目启动速度优化的一些内容，大部分其实就是减少启动时扫描的包，但检查了整个项目，其实我们的项目包扫描的粒度已经很合适了，没有优化的空间。想到改造前后最大的区别就在于数据层的不同，感觉可能是引入了JPA影响，毕竟JPA是面向接口编程，而且项目中定义的JPA接口有100+个，项目启动时动态代理加载的类比较多，导致启动速度比较慢。有了排查方向，后面就比较好处理。

### 三、懒加载 ###

因为猜测是项目启动的时候加载的类比较多导致的，于是通过懒加载的方式看一下启动效果。在StartServer用全局懒加载的方式启动项目：

public class StartServer { 
        public static void main(String[] args) { 
            //SpringApplication.run(StartServer.class, args);
            SpringApplicationBuilder builder = new SpringApplicationBuilder(StartServer.class);
            builder.lazyInitialization(true).run(args);
        }
    }

应用全局懒加载，项目从原先44s减少到30s，整体减少了10s+，但因为懒加载的方式，项目启动后有些页面会在首次访问时有几秒钟页面空白的情况，用户体验感不好。同时懒加载本身也会存在一些问题，可能会导致有一些类没法在项目启动的时候被检查到。整体上，运用懒加载这种方式并不太稳妥。

### 四、接口优化 ###

问题又绕回到了项目本身。想到项目启动过程一般是做了一些bean的初始化和注册操作，于是写个钩子函数，查看是那些bean消耗的时间比较多。工具打印出实例化操作大于100ms的bean：

@Component
    public class TimeBeanPostProcessor implements BeanPostProcessor { 
        private static final Map<String, Long> costMap = new ConcurrentHashMap<>();
        @Override
        public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { 
            costMap.put(beanName, System.currentTimeMillis());
            return bean;
        }
        @Override
        public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { 
            try { 
                long start = costMap.get(beanName);
                long cost  = System.currentTimeMillis() - start;
                if (cost > 100) { 
                    System.out.println("class: " + bean.getClass().getName()
                            + " bean: " + beanName
                            + " time: " + cost);
                }
                return bean;
            }catch (Exception e){ 
                e.printStackTrace();
            }
            return bean;
        }
    }

启动后发现耗费时间比较多的都是JPA相关的一些接口，也印证了上面对JPA动态代理影响的猜想。根据打印出来的内容可以发现动态代理都是通过jdk去实现，但SpringBoot2.x是默认cglib实现动态代理，这里就很奇怪。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzZjE1NzY4NjE1Mjg0_size_16_color_FFFFFF_t_70]  
查了下SpringBoot的源码，发现是在createAopProxy()中判断使用jdk动态代理还是cglib动态代理，同时对于AdvisedSupport中初始化ProxyTargetClass的值是true，但isProxyTargetClass()拿出来是false，可见在程序运行的过程中ProxyFactory（代理工厂）被修改了。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzZjE1NzY4NjE1Mjg0_size_16_color_FFFFFF_t_70 1]根据debug结果可以看到，当前代理工厂的对象是CrudMethodMetadata，查看该对象发现在程序执行过程中重新new了一个ProxyFactory，默认proxyTargetClass是false，所以代理最后是采用了jdk的方式，整体上到这里好像没有什么特别的地方。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzZjE1NzY4NjE1Mjg0_size_16_color_FFFFFF_t_70 2]继续查看了getCrudMethodMetadata()的调用，比较特别的地方出现了。可以发现SpringDataJPA是默认支持QueryDsl的，会为QueryDsl类型的接口新生成一个代理工厂，而项目中正好接入QueryDsl实现一些复杂查询。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzZjE1NzY4NjE1Mjg0_size_16_color_FFFFFF_t_70 3]  
回到项目代码，在项目改造初期为了方便操作封装了JPA和QueryDsl的接口，也正好是这个接口，使得每一个实现它的接口会被代理2次，一次是JPA原生的代理，一次是QueryDsl的代理，而QuerydslPredicateExecutor提供的方法里JpaRepositoryImplementation里都有，没有必要重复引入，去掉就好了。

//修改前
    @NoRepositoryBean
    public interface CoreDao<T, ID extends Serializable> extends JpaRepositoryImplementation<T, ID>, QuerydslPredicateExecutor<T> { 
    }
    //修改后
    @NoRepositoryBean
    public interface CoreDao<T, ID extends Serializable> extends JpaRepositoryImplementation<T, ID> { 
    }

重启项目，启动时间减少为27s左右，基本满足开发、调试和部署。所以在引入一个新的技术的时候最好要对其有比较完整的了解，避免挖坑。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzZjE1NzY4NjE1Mjg0_size_16_color_FFFFFF_t_70]: /images/20230209/a12675f5b27c41ad88ab5f62f791ea9c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzZjE1NzY4NjE1Mjg0_size_16_color_FFFFFF_t_70 1]: /images/20230209/b695080d95da46368e6b4e26a231050b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzZjE1NzY4NjE1Mjg0_size_16_color_FFFFFF_t_70 2]: /images/20230209/5d1720608a624b9faaea43e3038782cb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzZjE1NzY4NjE1Mjg0_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200721223132801.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzZjE1NzY4NjE1Mjg0,size_16,color_FFFFFF,t_70