hibernate之延迟加载(Lazy Loading)

本文介绍了Hibernate中的延迟加载机制,包括实体对象、集合和属性级别的延迟加载。解释了如何配置及其实现原理,如使用CGLib创建代理对象来实现按需加载数据。

避免在某些情况下,关联关系给我们带来无谓的开销,Hibernate引入了延迟加载的概念;

Hibernate3中的延迟记载可以针对:

  • 实体对象
  • 集合(Collection)
  • 属性的延迟加载

通过Load方法,可以返回目标实体对象的代理;

1,针对实体对象的延迟加载:

在class标签里添加lazy="true",属性:

	<class name="TUser" table="t_user" lazy="true">	

 如果将lazy="false"时,当程序运行:

TUser user = (TUser) session.load(TUser.class, new Integer(1));

 时,会发出SQL,从数据库中取出所对应的记录,并构造了一个完整的TUser对象;

如果将lazy="true"后,程序执行到:

TUser user = (TUser) session.load(TUser.class, new Integer(1));

 时,并没有任何SQL语句发出,此时对象里的属性也为空,当程序执行到:

System.out.println("user Name:"+users.getName());

 时,可以用Eclipse的Debug看到对象的属性仍然为空,但是看日志输出,会发现已经发出SQL,并也取到了其想要的name名字;

 

延迟加载和非延迟加载的差异在于Hibernate的代理机制,Hibernate引入了CGLib作为代理机制的实现,也就是我们在DeBug下可以看到TUser$EnhancerByCGLIB$$bede8986类型对象的原因;

CGLIB可以在运行期生成 java Class,这里的代理机制,其基本原理就是通过由CGLIB构造一个包含目标对象所有属性和方法的动态对象(相当于动态构造目标对象的一个子类)返回,并以之作为中介,为目标对象提供更多的特性;

这时,真正的TUser对象,位于代理类的CGLIB$CALLBACK_0.target属性中,当我们调用getName()方法时,实际上调用的是CGLIB$CALLBACK_0.getName()方法,当调用了CGLIB$CALLBACK_0.getName()后,首先会检查 CGLIB$CALLBACK_0.target中是否存在目标对象;如果存在,则调用目标对象的getName方法返回,如果目标对象为空,则发起数据库查询指令,读取记录,构建目标对象并将其设入CGLIB$CALLBACK_0.target。这样,通过一个中间代理,实现数据延迟加载功能,只有当用户真正的调用实体类的取值方法,Hibernate才会去数据库中取值;

2,类型集合的延迟加载

假如我们有个TUser实体对象,这个对象里面有Set<Book> books;属性;在我们获取TUser基本信息的时候,不必要将books一起查出来,这样的话可以给<set />标签添加lazy属性;

		<set name="books" cascade="all" lazy="true">

 这样的话,只有我们实际中真正的用到book了,才会去数据库里查询!

3,属性延迟加载

现将其属性设置:

		<property name="name" lazy="true"/>

配置了lazy属性之外,还要借助类增强器对二进制Class文件进行强化处理(buildtime bytecode instrumentation)。通过ANT调用Hibernate类增强器对TUser.class文件进行强化处理。脚本如下:

<project name="HibernateSample" default="instrument" basedir=".">
  <property name="lib.dir" value="./lib"/>
  <property name="classes.dir" value="./bin"/>
  
  <path id="lib.class.path">
     <fileset dir="${lib.dir}">
         <include name="**/*.jar"/>
     </fileset>
   
  <target name="instrument">
     <taskdef name="instrument"
         classname="org.hibernate.tool.instrument.InstrumentTask">

        <classpath path="${classes.dir}"/>
        <classpath refid="lib.class.path"/>
     </taskdef>
        
     <instrument verbose="true">
        <fileset dir="${classes.dir}/com.redsaga/hibernate/db/entity">
           <include name="TUser.class"/>
        </fileset>
     </instrument>
  </target>
</project>
 
内容概要:本文围绕“基于交流潮流的电力系统多元件N-k故障模型研究”展开,深入探讨了利用Matlab代码实现电力系统在发生多个关键元件同时故障(即N-k故障)情况下的交流潮流计算与故障分析方法。该模型不仅考虑了传统潮流方程的非线性特性,还引入了故障约束条件,能够精确模拟复杂多样的故障场景,如短路、断线等,进而评估电网在极端运行条件下的稳态与动态行为。研究通过构建典型电力系统算例,验证了所提模型在故障筛选、脆弱性识别及系统恢复策略制定方面的有效性,为电力系统安全评估、风险预警和防御体系构建提供了坚实的理论依据和技术支撑。此外,模型具备良好的扩展性,可进一步应用于连锁故障传播分析、恶意攻击模拟等高级安全分析领域。; 适合人群:具备电力系统分析基础理论知识和Matlab编程能力的高校研究生、科研院所研究人员以及电力公司从事电网规划、运行与安全管理的技术人员,特别适用于开展电力系统安全稳定、可靠性评估与应急响应机制研究的专业人士。; 使用场景及目标:①开展电力系统在多重故障条件下的交流潮流仿真,评估系统电压稳定性、线路过载风险及负荷损失程度;②识别电网中的关键薄弱环节与脆弱元件,支撑电网加固改造与防御资源配置;③用于科研项目中的故障场景建模与算法验证,或作为教学案例帮助学生理解复杂故障下的系统响应机制。; 阅读建议:此资源以Matlab代码为核心实现手段,建议读者结合理论推导与代码实现进行对照学习,重点关注故障建模过程中雅可比矩阵的修正方法、故障注入方式及收敛性处理策略,建议在仿真中逐步增加故障数量与复杂度,深入理解N-k故障对系统潮流分布的影响规律,并尝试将其拓展至含新能源接入的现代电力系统场景中进行验证与优化。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值