从源码上分析hibernate的load和get之间的区别

一说到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

相关文章:

作者: flym

I am flym,the master of the site:)

发表评论

电子邮件地址不会被公开。 必填项已用*标注