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