Hibernate的批量处理

Hibernate批量处理其实从性能上考虑 它是很不可取的 浪费了很大的内存 从它的机制上讲 Hibernate它是先把符合条件的数据查出来 放到内存当中 然后再进行 *** 作 实际使用下来性能非常不理想 在笔者的实际使用中采用下面的第三种优化方案的数据是 条数据插入数据库 主流台式机的配置 需要约 分钟 呵呵 晕倒

总结下来有三种来处理以解决性能问题

绕过Hibernate API 直接通过 JDBC API 来做 这个方法性能上是比较好的 也是最快的

运用存储过程

还是用Hibernate API 来进行常规的批量处理 可以也有变 变就变在 我们可以在查找出一定的量的时候 及时的将这些数据做完 *** 作就

删掉 session flush（） session evict（XX对象集） 这样也可以挽救一点性能损失 这个 一定的量 要就要根据实际情况做定量参考了 一般为 左右 但效果仍然不理想

绕过Hibernate API 直接通过 JDBC API 来做 这个方法性能上是比较好的 也是最快的 （实例为 更新 *** 作）

Transaction tx=session beginTransaction（） //注意用的是hibernate事务处理边界

Connection conn=nnection（）

PreparedStatement stmt=conn preparedStatement（ update CUSTOMER as C set C sarlary=c sarlary+ where c sarlary>）

stmt excuteUpdate（）

mit（） //注意用的是hibernate事务处理边界

这小程序中 采用的是直接调用JDBC 的API 来访问数据库 效率很高 避免了Hibernate 先查询出来加载到内存 再进行 *** 作引发的性能问题

运用存储过程 但这种方式考虑到易植和程序部署的方便性 不建议使用 （实例为 更新 *** 作）

如果底层数据库（如Oracle）支持存储过程 也可以通过存储过程来执行批量更新 存储过程直接在数据库中运行 速度更加快 在Oracle数

据库中可以定义一个名为batchUpdateCustomer（）的存储过程 代码如下

代码内容create or replace procedure batchUpdateCustomer（p_age in number） as begin update CUSTOMERS set AGE=AGE+ where AGE>p_age end

以上存储过程有一个参数p_age 代表客户的年龄 应用程序可按照以下方式调用存储过程

代码内容

tx = session beginTransaction（）

Connection con=nnection（）

String procedure = {call batchUpdateCustomer（？） }

CallableStatement cstmt = con prepareCall（procedure）

cstmt setInt（ ） //把年龄参数设为

cstmt executeUpdate（）

mit（）

从上面程序看出 应用程序也必须绕过Hibernate API 直接通过JDBC API来调用存储过程

还是用Hibernate API 来进行常规的批量处理 可以也有变 变就变在 我们可以在查找出一定的量的时候 及时的将这些数据做完 *** 作就

删掉 session flush（） session evict（XX对象集） 这样也可以挽救一点性能损失 这个 一定的量 要就要根据实际情况做定量参考了……

（实例为 保存 *** 作）

业务逻辑为 我们要想数据库插入 条数据

tx=session beginTransaction（）

for（int i= i<i++）

{

Customer custom=new Customer（）

custom setName（ user +i）

session save（custom）

if（i% == ） // 以每 个数据作为一个处理单元 也就是我上面说的 一定的量 这个量是要酌情考虑的

{

session flush（）

session clear（）

}

}

这样可以把系统维持在一个稳定的范围……

在项目的开发过程之中 由于项目需求 我们常常需要把大批量的数据插入到数据库 数量级有万级 十万级 百万级 甚至千万级别的 如此数量级别的数据用Hibernate做插入 *** 作 就可能会发生异常 常见的异常是OutOfMemoryError（内存溢出异常）

首先 我们简单来回顾一下Hibernate插入 *** 作的机制 Hibernate要对它内部缓存进行维护 当我们执行插入 *** 作时 就会把要 *** 作的对象全部放到自身的内部缓存来进行管理

谈到Hibernate的缓存 Hibernate有内部缓存与二级缓存之说 由于Hibernate对这两种缓存有着不同的管理机制 对于二级缓存 我们可以对它的大小进行相关配置 而对于内部缓存 Hibernate就采取了 放任自流 的态度了 对它的容量并没有限制 现在症结找到了 我们做海量数据插入的时候 生成这么多的对象就会被纳入内部缓存（内部缓存是在内存中做缓存的） 这样你的系统内存就会一点一点的被蚕食 如果最后系统被挤 炸 了 也就在情理之中了

我们想想如何较好的处理这个问题呢？有的开发条件又必须使用Hibernate来处理 当然有的项目比较灵活 可以去寻求其他的方法

笔者在这里推荐两种方法 （ ） 优化Hibernate 程序上采用分段插入及时清除缓存的方法

（ ） 绕过Hibernate API 直接通过 JDBC API 来做批量插入 这个方法性能上是最 好的 也是最快的

对于上述中的方法 其基本是思路为 优化Hibernate 在配置文件中设置hibernate jdbc batch_size参数 来指定每次提交SQL的数量 程序上采用分段插入及时清除缓存的方法（Session实现了异步write behind 它允许Hibernate显式地写 *** 作的批处理） 也就是每插入一定量的数据后及时的把它们从内部缓存中清除掉 释放占用的内存

设置hibernate jdbc batch_size参数 可参考如下配置

<hibernate configuration><session factory>……

<property name= hibernate jdbc batch_size ></property>……

<session factory><hibernate configuration>

配置hibernate jdbc batch_size参数的原因就是尽量少读数据库 hibernate jdbc batch_size参数值越大 读数据库的次数越少 速度越快 从上面的配置可以看出 Hibernate是等到程序积累到了 个SQL之后再批量提交

笔者也在想 hibernate jdbc batch_size参数值也可能不是设置得越大越好 从性能角度上讲还有待商榷 这要考虑实际情况 酌情设置 一般情形设置 就可以满足需求了

程序实现方面 笔者以插入 条数据为例子 如

Session session=HibernateUtil currentSession（）

Transatcion tx=session beginTransaction（）

for（int i= i<i++）

{

Student st=new Student（）

st setName（ feifei ）

session save（st）

if（i% == ） //以每 个数据作为一个处理单元

{

session flush（） //保持与数据库数据的同步

session clear（） //清除内部缓存的全部数据 及时释放出占用的内存

}

}

mit（）

……

在一定的数据规模下 这种做法可以把系统内存资源维持在一个相对稳定的范围

注意 前面提到二级缓存 笔者在这里有必要再提一下 如果启用了二级缓存 从机制上讲Hibernate为了维护二级缓存 我们在做插入 更新 删除 *** 作时 Hibernate都会往二级缓存充入相应的数据 性能上就会有很大损失 所以笔者建议在批处理情况下禁用二级缓存

对于方法 采用传统的JDBC的批处理 使用JDBC API来处理

些方法请参照java 批处理自执行SQL

看看上面的代码 是不是总觉得有不妥的地方？对 没发现么！这还是JDBC的传统编程 没有一点Hibernate味道

可以对以上的代码修改成下面这样

Transaction tx=session beginTransaction（） //使用Hibernate事务处理

边界Connection conn=nnection（）

PrepareStatement stmt=conn prepareStatement（ insert into T_STUDENT（name） values（？） ）

for（int j= j++ j<）{

for（int i= i++ j<）

{

stmt setString（ feifei ）

}

}

stmt executeUpdate（）

mit（） //使用 Hibernate事务处理边界

……

这样改动就很有Hibernate的味道了 笔者经过测试 采用JDBC API来做批量处理 性能上比使用Hibernate API要高将近 倍 性能上JDBC 占优这是无疑的

批量更新与删除

Hibernate 中 对于批量更新 *** 作 Hibernate是将符合要求的数据查出来 然后再做更新 *** 作 批量删除也是这样 先把符合条件的数据查出来 然后再做删除 *** 作

这样有两个大缺点 （ ） 占用大量的内存

（ ） 处理海量数据的时候 执行update/delete语句就是海量了 而且一条update/delete语句只能 *** 作一个对象 这样频繁的 *** 作数据库 性能低下应该是可想而知的了

Hibernate 发布后 对批量更新/删除 *** 作引入了bulk update/delete 其原理就是通过一条HQL语句完成批量更新/删除 *** 作 很类似JDBC的批量更新/删除 *** 作 在性能上 比Hibernate 的批量更新/删除有很大的提升

Transaction tx=session beginSession（）

String HQL= delete STUDENT

Query query=session createQuery（HQL）

int size=query executeUpdate（）

mit（）

……

控制台输出了也就一条删除语句Hibernate delete from T_STUDENT 语句执行少了 性能上也与使用JDBC相差无几 是一个提升性能很好的方法 当然为了有更好的性能 笔者建议批量更新与删除 *** 作还是使用JDBC 方法以及基本的知识点与上面的批量插入方法 基本相同 这里就不在冗述

笔者这里再提供一个方法 就是从数据库端来考虑提升性能 在Hibernate程序端调用存储过程 存储过程在数据库端运行 速度更快 以批量更新为例 给出参考代码

首先在数据库端建立名为batchUpdateStudent存储过程

create or replace produre batchUpdateStudent（a in number） as

begin

update STUDENT set AGE=AGE+ where AGE>a

end

调用代码如下

Transaction tx=session beginSession（）

Connection conn=nnection（）

String pd= ……{call batchUpdateStudent（？）}

CallableStatement cstmt=conn PrepareCall（pd）

cstmt setInt（ ） //把年龄这个参数设为

mit（）

观察上面的代码 也是绕过Hibernate API 使用 JDBC API来调用存储过程 使用的还是Hibernate的事务边界 存储过程无疑是提高批量处理性能的一个好方法 直接运行与数据库端 某种程度上讲把批处理的压力转接给了数据库

三 编后语

本文探讨了Hibernate的批处理 *** 作 出发点都是在提高性能上考虑了 也只是提供了提升性能的一个小方面

lishixinzhi/Article/program/Java/ky/201311/28885

一 批量修改和删除

在Hibernate 中 如果需要对任何数据进行修改和删除 *** 作 都需要先执行查询 *** 作 在得到要修改或者删除的数据后 再对该数据进行相应的 *** 作处理 在数据量少的情况下采用这种处理方式没有问题 但需要处理大量数据的时候就可能存在以下的问题

占用大量的内存

需要多次执行update/delete语句 而每次执行只能处理一条数据

以上两个问题的出现会严重影响系统的性能 因此 在Hibernate 中引入了用于批量更新或者删除数据的HQL语句 这样 开发人员就可以一次更新或者删除多条记录 而不用每次都一个一个地修改或者删除记录了

如果要删除所有的User对象(也就是User对象所对应表中的记录) 则可以直接使用下面的HQL语句

delete User

而在执行这个HQL语句时 需要调用Query对象的executeUpdate()方法 具体的实例如下所示

String HQL= delete User

Query query=session createQuery(HQL)

int size=query executeUpdate()

采用这种方式进行数据的修改和删除时与直接使用JDBC的方式在性能上相差无几 是推荐使用的正确方法

如果不能采用HQL语句进行大量数据的修改 也就是说只能使用取出再修改的方式时 也会遇到批量插入时的内存溢出问题 所以也要采用上面所提供的处理方法来进行类似的处理

二 使用SQL执行批量 *** 作

在进行批量插入 修改和删除 *** 作时 直接使用JDBC来执行原生态的SQL语句无疑会获得最佳的性能 这是因为在处理的过程中省略或者简化了以下处理内容

● HQL语句到SQL语句的转换

● Java对象的初始化

● Java对象的缓存处理

但是在直接使用JDBC执行SQL语句时 有一个最重要的问题就是要处理缓存中的Java对象 因为通过这种底层方式对数据的修改将不能通知缓存去进行相应的更新 *** 作 以保证缓存中的对象与数据库中的数据是一致的

三 提升数据库查询的性能

数据库查询性能的提升也是涉及到开发中的各个阶段 在开发中选用正确的查询方法无疑是最基础也最简单的

SQL语句的优化

使用正确的SQL语句可以在很大程度上提高系统的查询性能 获得同样数据而采用不同方式的SQL语句在性能上的差距可能是十分巨大的

由于Hibernate是对JDBC的封装 SQL语句的产生都是动态由Hibernate自动完成的 Hibernate产生SQL语句的方式有两种 一种是通过开发人员编写的HQL语句来生成 另一种是依据开发人员对关联对象的访问来自动生成相应的SQL语句

至于使用什么样的SQL语句可以获得更好的性能要依据数据库的结构以及所要获取数据的具体情况来进行处理 在确定了所要执行的SQL语句后 可以通过以下三个方面来影响Hibernate所生成的SQL语句

HQL语句的书写方法

查询时所使用的查询方法

对象关联时所使用的抓取策略

使用正确的查询方法

在前面已经介绍过 执行数据查询功能的基本方法有两种 一种是得到单个持久化对象的get()方法和load()方法 另一种是Query对象的list()方法和iterator()方法 在开发中应该依据不同的情况选用正确的方法

get()方法和load()方法的区别在于对二级缓存的使用上 load()方法会使用二级缓存 而get()方法在一级缓存没有找到的情况下会直接查询数据库 不会去二级缓存中查找 在使用中 对使用了二级缓存的对象进行查询时最好使用load()方法 以充分利用二级缓存来提高检索的效率

list()方法和iterator()方法之间的区别可以从以下几个方面来进行比较

执行的查询不同

list()方法在执行时 是直接运行查询结果所需要的查询语句 而iterator()方法则是先执行得到对象ID的查询 然后再根据每个ID值去取得所要查询的对象 因此 对于list()方式的查询通常只会执行一个SQL语句 而对于iterator()方法的查询则可能需要执行N+ 条SQL语句(N为结果集中的记录数)

iterator()方法只是可能执行N+ 条数据 具体执行SQL语句的数量取决于缓存的情况以及对结果集的访问情况

缓存的使用

list()方法只能使用二级缓存中的查询缓存 而无法使用二级缓存对单个对象的缓存(但是会把查询出的对象放入二级缓存中) 所以 除非重复执行相同的查询 *** 作 否则无法利用缓存的机制来提高查询的效率

iterator()方法则可以充分利用二级缓存 在根据ID检索对象的时候会首先到缓存中查找 只有在找不到的情况下才会执行相应的查询语句 所以 缓存中对象的存在与否会影响到SQL语句的执行数量

对于结果集的处理方法不同

list()方法会一次获得所有的结果集对象 而且它会依据查询的结果初始化所有的结果集对象 这在结果集非常大的时候必然会占据非常多的内存 甚至会造成内存溢出情况的发生

iterator()方法在执行时不会一次初始化所有的对象 而是根据对结果集的访问情况来初始化对象 因此在访问中可以控制缓存中对象的数量 以避免占用过多缓存 导致内存溢出情况的发生 使用iterator()方法的另外一个好处是 如果只需要结果集中的部分记录 那么没有被用到的结果对象根本不会被初始化 所以 对结果集的访问情况也是调用iterator()方法时执行数据库SQL语句多少的一个因素

所以 在使用Query对象执行数据查询时应该从以上几个方面去考虑使用何种方法来执行数据库的查询 *** 作

四 使用正确的抓取策略

所谓抓取策略(fetching strategy)是指当应用程序需要利用关联关系进行对象获取的时候 Hibernate获取关联对象的策略 抓取策略可以在O/R映射的元数据中声明 也可以在特定的HQL或条件查询中声明

Hibernate 定义了以下几种抓取策略

连接抓取(Join fetching)

连接抓取是指Hibernate在获得关联对象时会在SELECT语句中使用外连接的方式来获得关联对象

查询抓取(Select fetching)

查询抓取是指Hibernate通过另外一条SELECT语句来抓取当前对象的关联对象的方式 这也是通过外键的方式来执行数据库的查询 与连接抓取的区别在于 通常情况下这个SELECT语句不是立即执行的 而是在访问到关联对象的时候才会执行

子查询抓取(Subselect fetching)

子查询抓取也是指Hibernate通过另外一条SELECT语句来抓取当前对象的关联对象的方式 与查询抓取的区别在于它所采用的SELECT语句的方式为子查询 而不是通过外连接

批量抓取(Batch fetching)

批量抓取是对查询抓取的优化 它会依据主键或者外键的列表来通过单条SELECT语句实现管理对象的批量抓取

以上介绍的是Hibernate 所提供的抓取策略 也就是抓取关联对象的手段 为了提升系统的性能 在抓取关联对象的时机上 还有以下一些选择

立即抓取(Immediate fetching)

立即抓取是指宿主对象被加载时 它所关联的对象也会被立即加载

延迟集合抓取(Lazy collection fetching)

延迟集合抓取是指在加载宿主对象时 并不立即加载它所关联的对象 而是到应用程序访问关联对象的时候才抓取关联对象 这是集合关联对象的默认行为

延迟代理抓取(Lazy proxy fetching)

延迟代理抓取是指在返回单值关联对象的情况下 并不在对其进行get *** 作时抓取 而是直到调用其某个方法的时候才会抓取这个对象

延迟属性加载(Lazy attribute fetching)

延迟属性加载是指在关联对象被访问的时候才进行关联对象的抓取

介绍了Hibernate所提供的关联对象的抓取方法和抓取时机 这两个方面的因素都会影响Hibernate的抓取行为 最重要的是要清楚这两方面的影响是不同的 不要将这两个因素混淆 在开发中要结合实际情况选用正确的抓取策略和合适的抓取时机

抓取时机的选择

在Hibernate 中 对于集合类型的关联在默认情况下会使用延迟集合加载的抓取时机 而对于返回单值类型的关联在默认情况下会使用延迟代理抓取的抓取时机

对于立即抓取在开发中很少被用到 因为这很可能会造成不必要的数据库 *** 作 从而影响系统的性能 当宿主对象和关联对象总是被同时访问的时候才有可能会用到这种抓取时机 另外 使用立即连接抓取可以通过外连接来减少查询SQL语句的数量 所以 也会在某些特殊的情况下使用

然而 延迟加载又会面临另外一个问题 如果在Session关闭前关联对象没有被实例化 那么在访问关联对象的时候就会抛出异常 处理的方法就是在事务提交之前就完成对关联对象的访问

所以 在通常情况下都会使用延迟的方式来抓取关联的对象 因为每个立即抓取都会导致关联对象的立即实例化 太多的立即抓取关联会导致大量的对象被实例化 从而占用过多的内存资源

抓取策略的选取

对于抓取策略的选取将影响到抓取关联对象的方式 也就是抓取关联对象时所执行的SQL语句 这就要根据实际的业务需求 数据的数量以及数据库的结构来进行选择了

在这里需要注意的是 通常情况下都会在执行查询的时候针对每个查询来指定对其合适的抓取策略 指定抓取策略的方法如下所示

User user = (User) session createCriteria(User class)

setFetchMode( permissions FetchMode JOIN)

add( Restrictions idEq(userId) )

uniqueResult()

五 查询性能提升小结

在本小节中介绍了查询性能提升的方法 关键是如何通过优化SQL语句来提升系统的查询性能 查询方法和抓取策略的影响也是通过执行查询方式和SQL语句的多少来改变系统的性能的 这些都属于开发人员所应该掌握的基本技能 避免由于开发不当而导致系统性能的低下

在性能调整中 除了前面介绍的执行SQL语句的因素外 对于缓存的使用也会影响系统的性能 通常来说 缓存的使用会增加系统查询的性能 而降低系统增加 修改和删除 *** 作的性能(因为要进行缓存的同步处理) 所以 开发人员应该能够正确地使用有效的缓存来提高数据查询的性能 而要避免滥用缓存而导致的系统性能变低 在采用缓存的时候也应该注意调整自己的检索策略和查询方法 这三者配合起来才可以达到最优的性能

lishixinzhi/Article/program/Java/ky/201311/28720

使用update 更新修改数据库数据,更改的结果集是多条数据则为批量修改。

语法格式如：

update 表格 set 列 = 更改值 where 筛选条件

例：

update table set a=1 --将table 中所以a列的值改为 1

update table set a=1 where b=2 --将table 中列b=2的记录中a列的值改为 1

---