一说到hibernate的get和load之间的区别,大多数网上的都会说出如下的区别:get不走缓存,load走缓存;或者get不会使用二级缓存之类,然而这些都是错误的。其实两者没有大多的区别,真正的区别在于二者获取对象的方式,以及如何使用对象上。本文从源码分析上分析两者的具体区别。本方使用的hibernate 版本为3.6.3。
获取对象的API,二者都使用统一的方式调用,如下所示:
来源于sessionImpl load的api: LoadEvent event = new LoadEvent(id, entityName, false, this); fireLoad( event, LoadEventListener.LOAD ); get的api: LoadEvent event = new LoadEvent(id, entityName, false, this); fireLoad(event, LoadEventListener.GET);
可以看出,二者的api都一样,主要的不一样在于,触发事件的方式不一样。load时使用LoadEventListener.LOAD而get时使用LoadEventListener.GET。我们看看两者的具体不一样:
public static final LoadType GET = new LoadType("GET") .setAllowNulls(true) .setAllowProxyCreation(false) .setCheckDeleted(true) .setNakedEntityReturned(false); public static final LoadType LOAD = new LoadType("LOAD") .setAllowNulls(false) .setAllowProxyCreation(true) .setCheckDeleted(true) .setNakedEntityReturned(false);
主要的区别在于:在allowNulls上get允许而load不允许,allowProxyCreation上get不允许而load允许。具体这两者的区别在哪儿,我们进一步地从源码上进行分析。
sessionImpl的fireLoad方法,最终会调用到 loadEventListener[i].onLoad(event, loadType)方法,而此方法会走向
DefaultLoadListener public void onLoad(LoadEvent event, LoadEventListener.LoadType loadType) throws HibernateException //第152行 event.setResult( proxyOrLoad(event, persister, keyToLoad, loadType) );
即调用proxyOrLoad中,这时get和load都是走的同一个逻辑,那么接下来看具体的proxyOrLoad实现
类DefaultLoadEventListener.proxyOrLoad方法: // look for a proxy Object proxy = persistenceContext.getProxy(keyToLoad); if ( proxy != null ) {//如果上下文中已有代理对象 分支1 return returnNarrowedProxy( event, persister, keyToLoad, options, persistenceContext, proxy ); } else { if ( options.isAllowProxyCreation() ) //允许创建代理,即load方式,分支2 return createProxyIfNecessary( event, persister, keyToLoad, options, persistenceContext ); else //直接返回loaded对象,即get方式 分支3 return load(event, persister, keyToLoad, options); }
这里有三个分支,第一个如果上下文中已经有代理对象,那么将继续根据get或load加载对象。而否则将分别进入到createProxyIfNecessary或load方法。
分支2:load创建代理
进入到createProxyIfNecessary方法,如下所示:;
Object existing = persistenceContext.getEntity( keyToLoad ) if ( existing != null ) { ......//已经在上下文中存在了 return existing; } else { // return new uninitialized proxy 创建未实例化的代理,并直接返回之 Object proxy = persister.createProxy( event.getEntityId(), event.getSession() ); persistenceContext.getBatchFetchQueue().addBatchLoadableEntityKey(keyToLoad); persistenceContext.addProxy(keyToLoad, proxy); return proxy; }
从上面的代码,可以看出,load的工作方式首先查询上下文(即缓存),如果存在则返回之。否则直接创建一个代理对象就返回,也就是说,这里根本就不会发送相应的sql进行数据库查询,而是直接返回相应的对象即可,不管给定的id是否在数据库中存在数据对象。
分支3:get获取对象
在load内部最终会调用到doLoad方法,我们看下doLoad的最终实现:
DefaultLoadEventListener的doLoad方法doLoad(final LoadEvent event,final EntityPersister persister,final EntityKey keyToLoad,final LoadEventListener.LoadType options) //首先从session缓存,即一级缓存中找 Object entity = loadFromSessionCache( event, keyToLoad, options ); ...... //再从二级缓存中找,如果开了二级缓存 entity = loadFromSecondLevelCache(event, persister, options); ...... //最后,从数据库中找 return loadFromDatasource(event, persister, keyToLoad, options);
通过对分支3即get内部实现的查看,我们会发现,get首先会直接一级缓存,再二级缓存,最后才到数据库中找。那么load的最终工作方式是否也是这样呢,load最终也会查数据吧,那么它的工作方式是如何呢?
load如何加载数据
从分支1我们会看出load不会直接访问数据库,只是简单地返回一个由底层封装的一个代理对象。由于笔者使用的版本为3.6.3,所以底层使用了javassist来进行代理构建,那么它底层使用了JavassistLazyInitializer来表示最后的对象的handler处理器。那么我们说load只有在访问属性的时候才会去最终访问数据,所以我们来看如何进行访问最终数据的。定位到该类的invoke方法(此类是实现类MethodHandler接口的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 ); }
上面的实现,我们需要注意的有两点,一个是调用父类的invoke方法,第二个由是调用getImplementation。第一个invoke简单介绍下,其实就是由父类将通用的处理先行处理了,比如调用equals,hashcode以及内部使用的getHibernateLazyInitializer方法之类,具体实现可以查看类BasicLazyInitializer的具体实现。其它父类方法不能处理的由交由子类继续处理,即返回一个INVOKE_IMPLEMENTATION的标记,由子类再继续处理。第二个方法是这里的重点,它揭示了hibernate如何重新获取数据并实例化该数据,看代码如下所示:
public final Object getImplementation() { initialize();//初始化对象,或者叫实例化对象 return target; } public final void initialize() throws HibernateException { if (!initialized) { target = session.immediateLoad(entityName, id);//调用session,立即加载相应对象 initialized = true; checkTargetState(); } }
上面的代码,揭示了hibernate如何具体 初始化一个代理的对象,即调用session的immediateLoad方法加载一个对象。此immediateLoad我们说它的实现与get方法差不多,具体可以查看相应的实现,也是通过一级,二级缓存最后到数据库的一个过程。
然后还需要注意的就是这里的checkTargetState,为什么说load返回的对象,在调用属性时如果此对象为空,会报一个对象不存在的错误。其最终的实现就是这里的checkTargetState,看简单实现如下:
private void checkTargetState() { if ( !unwrap ) { if ( target == null ) { getSession().getFactory().getEntityNotFoundDelegate().handleEntityNotFound( entityName, id ); } } }
其实就是如果为空,这里就抛出异常,并处理出,一般就是直接抛出一个异常。
分支1:已有对象处理
我们最后讨论在load和get时,如果上下文也有代理的情况,因为这只是其中处理的一个小的分支。也就是根据load和get的不同进行简单处理,具体实现如下:
LazyInitializer li = ( (HibernateProxy) proxy ).getHibernateLazyInitializer(); if ( li.isUnwrap() ) { return li.getImplementation();//返回最终的实现 } Object impl = null; if ( !options.isAllowProxyCreation() ) { impl = load( event, persister, keyToLoad, options );//不允许代理时,直接返回之 } //重新封装一次代理信息 return persistenceContext.narrowProxy( proxy, persister, keyToLoad, impl );
所以,如果当前上下文上也有代理对象,则直接处理此代理对象,根据get或load的方式决定是否加载此对象还是解包再封装一下。
总结:
从以上的源码分析来看,get和load的区别不是很大,主要是用处不一样。两个的区别在于获取数据的时机不一样,在正常的情况下两者都适合于常规的数据关系操作。如果很在意操作的对象信息一定要在数据库中存在的话,建议使用get,因为它的返回值直接就反映了数据库中是否存在这么一条数据;而load则是任何时候都会返回一个非null值,当要用的时候才对获取数据并验证,这与通常的理解有点偏差。但这种方式如果结合于数据库的约束器来使用的话,在某些情况下,可以减少数据库的查询数据的语句数。
至于缓存一说,get和load都会很好地利用到一级缓存和二级缓存,并且hibernate对于load产生的代理对象,专门在内部作了处理,使代理对象和常规的实体对象之间能够很好地协作和互转,所以不存在哪个有缓存,哪个无缓存的情况产生。
最后说下我个人的情况,由于个人对数据完整性要求较高,在保存数据到数据库之前,一定要验证数据的完整性,所以一直使用get方法,并由程序判断对象数据是否为null的情况;而load使用较少,加上使用了二级缓存(即以id缓存的主键对象),所以在数据查询上没有太大的数据访问问题。
转载请标明出处:i flym
本文地址:https://www.iflym.com/index.php/code/201112050001.html