很多人都对java在批量数据的处理方面是否是其合适的场所持有怀疑的念头，由此延伸，那么就会认为orm可能也不是特别适合数据的批量处理。 其实，我想如果我们应用得当的话，完全可以消除orm批量处理性能问题这方面的顾虑。下面以hibernate为例来做为说明，假如我们真的不得不在java中使用hibernate来对数据进行批量处理的话。 向数据库插入100 000条数据，用hibernate可能像这样：
session session = sessionfactory.opensession();
transaction tx = session.begintransaction();
for ( int i=0; i<100000; i++ ) {
customer customer = new customer(.....);
session.save(customer); }
tx.commit();
session.close();
大概在运行到第50 000条的时候，就会出现内存溢出而失败。这是hibernate把最近插入的customer都以session-level cache在内存做缓存，我们不要忘记hiberante并没有限制first-level cache 的缓存大小：
# 持久对象实例被管理在事务结束时，此时hibernate与数据库同步任何已经发生变 化的被管理的的对象。
# session实现了异步write-behind，它允许hibernate显式地写操作的批处理。 这里，我给出hibernate如何实现批量插入的方法：
首先，我们设置一个合理的jdbc批处理大小，hibernate.jdbc.batch_size 20。 然后在一定间隔对session进行flush()和clear()。
session session = sessionfactory.opensession();
transaction tx = session.begintransaction();
for ( int i=0; i<100000; i++ ) {
customer customer = new customer(.....);
session.save(customer);
if ( i % 20 == 0 ) {
//flush 插入数据和释放内存:
session.flush(); session.clear(); }
}
tx.commit();
session.close();
那么，关于怎样删除和更新数据呢？那好，在hibernate2.1.6或者更后版本，scroll() 这个方法将是最好的途径：
session session = sessionfactory.opensession();
transaction tx = session.begintransaction();
scrollableresults customers = session.getnamedquery("getcustomers")
.scroll(scrollmode.forward_only);
int count=0;
while ( customers.next() ) {
customer customer = (customer) customers.get(0);
customer.updatestuff(...);
if ( ++count % 20 == 0 ) {
//flush 更新数据和释放内存:
session.flush(); session.clear(); } }
tx.commit(); session.close();
这种做法并不困难，也不算不优雅。请注意，如果customer启用了second-level caching ，我们仍然会有一些内存管理的问题。原因就是对于用户的每一次插入和更新，hibernate在事务处理结束后不得不通告second-level cache 。因此，我们在批处理情况下将要禁用用户使用缓存。