Hibernate学习---检索优化

Hibernate框架对检索进行了优化，前面我们将CURD的时候提到了load和get的区别，当时仅仅说了load为延迟加载，get为立即加载，当检索的记录为空的时候load报错（不是在执行load方法的时候报的错，是执行后面的操作报的错），get返回null。

其实load就是对检索的一种优化，它的作用是当程序执行检索代码的时候，在缓存中没有的前提下，不会立即去数据库中查询，而是等真正用到的时候才会去查询，这是一种懒加载策略。

下面我们要讲的内容有：

当前对象的检索优化
关联对象的检索优化

当前对象的检索优化：

当前对象：这个概念存在于单表查询，可以认为是我们直接查询的对象（多表查询中我们有关联查询）。

当前对象的检索优化很简单，就是我们不使用get进行查询，使用load进行查询。我们的映射配置文件中有一个属性就是用来设置懒加载的：

这个lazy属性默认是true（我们不设置的时候），即当我们使用load进行查询的时候是进行懒加载的，当配置文件设置lazy设置为false的时候，即使使用load也是立即加载，还有一个为extra叫做特懒加载（能用聚合函数查询就不进行详情查询）。

上面就是对当前对象的检索优化，很简单。

但是我们要知道load底层的原理是什么，为什么当查询的记录不存的时候会报错：

Hibernate的load是通过动态代理获得我们想要查询的对象的，当执行load时候，它获得的是代理类对象，此时并没有真正执行查询语句，当真正需要数据的时候（例如前台请求，或者我们测试的时候输出结果），查询语句才会执行。所以当我们执行查询语句的时候才会真正调用真实对象的查询方法，并为代理对象初始化（需要查询的值）。

为啥会出错呢？

我们来看看出错的地方：

这个是实现动态代理类的invoke方法：

public Object invoke(

            final Object proxy,

            final Method thisMethod,

            final Method proceed,

            final Object[] args) throws Throwable {

        if ( this.constructed ) {

            Object result;

//调用父类的invoke方法

                result = this.invoke( thisMethod, args, proxy );

            //处理特殊返回结果

            if ( result == INVOKE_IMPLEMENTATION ) {

//最重要，这里最终会调用到获取最终数据的方法

                Object target = getImplementation();

                ......

//使用反射调用最终对象的最终方法，如xxx.getName()之类

                        returnValue = thisMethod.invoke( target, args );

    }

public final Object getImplementation() {

        initialize();//初始化对象，或者叫实例化对象

        return target;

    }

    public final void initialize() throws HibernateException {

        if (!initialized) {

                target = session.immediateLoad(entityName, id);//调用session，立即加载相应对象

                initialized = true;

                checkTargetState();//这个方法检查是否为空

                 }

    }

private void checkTargetState() {

        if ( !unwrap ) {

            if ( target == null ) {

                getSession().getFactory().getEntityNotFoundDelegate().handleEntityNotFound( entityName, id );//这里就是报错的根源

            }

        }

    }

以上的具体分析在我查到的一篇博客内有详细解答：

https://www.iflym.com/index.php/code/201112050001.html

关联对象的检索优化：

关联对象的检索优化分为两种：

多端加载优化
单端加载优化

我们先来说多端加载优化（我们下面所说的对一方查询都是使用HQL）：

所谓多端关联加载对象是指一方为主加载对象，而多端为从加载对象，对于多方加载时所进行的延迟加载配置。

既然是“一”方为主加载对象，那么就需要在“一”方进行配置，在进行配置之前我们先来看两组属性：

lazy我们都知道，fetch是什么呢（字面意思是：拿来取来）。

这个是fetch在配置文件中的位置，是set标签内的属性。

①当它为join的时候采用迫切左外连接（是立即加载，当配置这个属性的时候lazy失效）。当查找一方的时候因为我们使用的是左外连接（多表查询），所以效率上肯定比查找两张表的速度更快，即当查询一方的时候，多方的详情数据也被查询出来了。

②当fetch为select时，lazy为false时，采用普通select查询，当查询一方的时候，也会顺带将多方检查了，且都是通过直接查询加载的方式；lazy为true时，先查一方，多方为懒加载。

③当fetch为subselect时候，如果“一”里面有很多条记录，例如有三个部门，每个部门里面有十个员工，如果fetch为select，当遍历这些部门和员工的时候，每次都要先查询部门，然后再查询员工；但是如果使用子查询的话（fetch=“subselect”），只会查询一次部门详情，后面查询员工的时候不用再次查询部门，因为部门作为子查询进行。

说完多端加载优化我们再来说单端加载优化：

单端加载优化和多端加载优化用到的是同样的属性，但是它的属性取值不同且，配置是放在多方的。

单端的配置在many-to-one标签中配置fetch

①当fetch=“join”时，和多端一样，lazy失效，使用的是迫切左外连接。

②当fetch=“select”时也是采用普通select查询。

当lazy为proxy时候和no-proxy，它们的使用决定代理方式（懒加载方式），是否为懒加载还要看“一”方的配置。

关于检索优化就说到这里。

如有错误，不灵赐教。

巴特西

Hibernate学习---检索优化

当前对象的检索优化：

关联对象的检索优化：

最新文章

热门文章