尧图网站建设 
最近在带团队做一个老项目的性能优化发现不少人一提到Hibernate就先皱眉说它“重”、说它“慢”甚至直接问“这玩意儿还有人用吗”。这话题我太熟了。Hibernate作为Java界最老牌的ORM框架确实有过一些历史包袱但只要你把它的批量操作玩明白性能完全能打甚至能在某些场景下比手写JDBC更稳。这篇东西我不打算给你念文档就当一个用了十几年Hibernate的老兵给你捋一捋批量操作到底是什么、怎么用出效果、有哪些绕不开的坑。尤其是那些真正在高并发、大数据量场景下踩过雷的同学这篇应该能帮你省不少调试时间。如果你是刚接触Hibernate不久也完全能看懂我会把背后的原理也讲透。1. Hibernate批量操作是什么为什么总有人卡在这里很多新人第一次遇到“批量操作”这个需求处理方式非常直观写个for循环把实体一个个session.save()或者session.update()等循环结束再统一提交事务。小数据量跑起来没什么感觉最多慢一点。但一旦数据量上了万级你就会发现性能断崖式下跌甚至直接OOM。1.1 核心概念不是“批量”而是“攒一批”Hibernate里的批量操作准确说不是“批量”这俩字的字面意思而是把一批小操作合并成更少的大操作减少数据库往返次数同时控制自家的一级缓存不要无限膨胀。举个例子你要往一张表里插入10万条记录。如果你傻乎乎地for循环插入Hibernate每插入一条都会先检查一级缓存Session级别的缓存再往数据库发一条INSERT同时把实体对象存放在缓存里。10万条实体全堆在Session里不光内存爆炸光是那10万次数据库往返就够你喝一壶。所以批量操作的核心就三个字攒批、清缓存、走底层。1.2 适用场景哪些需求必须要批量不是所有代码都需要用批量操作。我个人在实际项目里的经验下面这几种场景必须认真考虑批量方案否则早晚出事数据迁移和初始化比如把一个旧系统的数据导入新系统每天定时跑条数都是十万起步。批量状态更新比如订单系统里定时任务把所有超时未支付的订单批量标记为“已取消”。报表或者ETL类的批量写库从外部文件读取大量数据解析后写入业务表。需要同时更新或删除一整个集合的数据比如按某个条件批量清空无效记录。这些场景的共同点很明显数据量大操作类型单一且重复。这正是批量操作能发挥最大价值的地方。1.3 为什么“Hibernate还有人用吗”会成为一个问题这里我想先回应一下那个热搜词“Hibernate还有人用吗”。说实话这个问题本身反映出很多团队其实没把Hibernate用对。如果你只会用最简单的session.save()那确实会被MyBatis按在地上摩擦。但Hibernate真正擅长的地方在于对象状态管理和二级缓存体系当你需要做复杂的关联关系维护、多级缓存策略或者赶项目进度需要快速建模时Hibernate的开发效率还是碾压级的。批量操作就是Hibernate从“能用”到“用好”之间最关键的一道坎。跨过去了你就知道怎么控制它而不是被它拖累。2. 两种最常用的批量写入方案JDBC批处理与StatelessSession先聊写入。写入是批量操作里使用频率最高的一种。在Hibernate圈子批量写入的解决方案主要有两个方向JDBC批处理和StatelessSession。这两个方案各有脾气选错了你就会觉得“还是用MyBatis吧”。2.1 JDBC批处理配置与原理JDBC批处理是利用数据库底层的PreparedStatement.addBatch()和executeBatch()能力把多条SQL攒在一起发给数据库由数据库一次性执行。Hibernate本身不关闭这个通道但你需要主动告诉它开启批处理并且告诉我攒几条发一次。第一步配置一个关键参数hibernate.jdbc.batch_size。这个参数决定了Hibernate攒多少条SQL之后真正向数据库发送一次。我一般建议设成20到50之间经验值是3的倍数原因是很多数据库驱动比如Oracle内部默认按3条一组来绑定参数不是倍数容易浪费批次的容量。以100为例含义是每调用100次session.save()Hibernate才向数据库真正发送一次批量INSERT。中间99次的SQL都被本地攒起来了。这样一来数据库往返次数就直接少了两个数量级。还有几个配套参数我列个表给你参考参数名推荐值作用hibernate.jdbc.batch_size20~50攒多少条SQL再发送太大会消耗应用内存hibernate.order_insertstrue对INSERT按实体类型排序让同一类型的INSERT能合并成批次hibernate.order_updatestrue对UPDATE按实体类型排序减少更新时的死锁风险hibernate.jdbc.batch_versioned_datatrue允许对版本化数据使用批处理默认是关闭的order_inserts和order_updates这两个参数特别容易被忽略。如果你的代码里交替穿插着不同类型的实体操作不排序的话批处理会被拆散效果大打折扣。给它们设成true等于先给所有SQL排队同类归置在一起再发车。第二步编码时要主动刷缓存。JDBC批处理虽然解决了数据库往返问题但一级缓存膨胀的问题还在。所以你必须在循环里定期调用session.flush()和session.clear()。flush()是把攒着的SQL按批次发出去clear()是清空一级缓存释放内存。建议在每插入batch_size条后做一次flush和clear这样内存水位能控制得住。下面写一个标准的JDBC批处理插入代码你直接可以抄作业Session session sessionFactory.openSession(); Transaction tx session.beginTransaction(); int batchSize 30; for (int i 0; i 100000; i) { User user new User(); user.setName(user_ i); user.setAge(i % 100); session.save(user); if (i % batchSize 0) { // 攒够一批推给数据库同时清空一级缓存 session.flush(); session.clear(); } } tx.commit(); session.close();这个代码里最容易出错的地方就是flush和clear的时机。flush太频繁会降低攒批效果flush太晚又容易内存爆炸。我实践中的做法是以batch_size为步长每步flush一次clear一次。这样实体对象不会在Session里堆积。对了还有个小技巧插入操作最好给主键生成器加上GeneratedValue(strategy GenerationType.SEQUENCE)这类数据库侧生成策略。如果你用的是IDENTITY数据库为了拿到自增主键会强制立即执行INSERT导致批处理被静默跳过。这是个很隐蔽的坑网上很多帖子都没说清楚你在做批量插入时一定要检查主键策略。2.2 StatelessSession无缓存批处理方案JDBC批处理虽然快但一级缓存总像个“包袱”——要管、要清、不能太满。这时候就该请出StatelessSession了。顾名思义无状态Session它完全不维护一级缓存也不管实体的状态管理实体对象进来直接就转换成SQL执行没有快照比对没有懒加载关联关系一切从简。使用方式上它和Session很像都是从SessionFactory获取。区别在于它没有flush()、没有clear()也不支持saveOrUpdate()这种级联操作就是最朴素的insert()、update()、delete()。StatelessSession session sessionFactory.openStatelessSession(); Transaction tx session.beginTransaction(); for (int i 0; i 100000; i) { User user new User(); user.setName(user_ i); user.setAge(i % 100); session.insert(user); } tx.commit(); session.close();注意虽然它叫“Stateless”但它身上还是可以配置hibernate.jdbc.batch_size底层依然会走JDBC批处理。所以官方其实推荐用StatelessSession来做纯批量写入启动快、内存占用低糙快猛。StatelessSession的代价就是失去了ORM的核心能力。它不会维护持久化上下文意味着你没法在同一个事务里先插一个订单再通过session.get()把它取回来继续操作因为这些实体根本没有被跟踪。所以它适合的场景是纯写入、纯删除、或者纯更新尤其是那种数据从文件或消息队列过来不需要回查的场景。2.3 二者对比什么时候选哪个我来整理一个对比表格方便你一眼看懂对比项Session JDBC批处理StatelessSession维护一级缓存是需手动flush/clear否零缓存支持级联操作支持不支持支持懒加载支持不支持内存占用高需小心溢出低几乎无累积适合场景业务实体关联复杂但量不大海量一次性写入、迁移批处理支持支持需配置batch_size支持同样需配置个人实践经验是如果单次事务里要处理的数据量超过1万条且实体对象不与其他实体有关联关系优先考虑StatelessSession。如果实体有关联、有级联、需要对象状态管理但又想提速则用Session加JDBC批处理。3. 批量更新与删除HQL的DML风格操作写入讲完了再来聊更新和删除。很多人批量更新用的方法很笨先session.createQuery(...).list()查出一大堆实体然后for循环改属性再让Hibernate自动更新。我对这种写法只有一句话形容又慢又要命。3.1 两条查询干掉一万次更新update/delete HQLHibernate里提供了一个“不讲武德”的批量更新方式直接在HQL里执行update或delete语句语法上几乎和SQL一致。它本质上走的是JDBC底层的batch能力但不用你把实体捞回内存再挨个改直接在数据库层面把事干了。典型的用法如下Session session sessionFactory.openSession(); Transaction tx session.beginTransaction(); String hql update User u set u.status :newStatus where u.age :age; int updatedCount session.createQuery(hql) .setParameter(newStatus, inactive) .setParameter(age, 18) .executeUpdate(); tx.commit(); session.close();就这么一条HQL你的批处理需求直接解决了。返回的updatedCount就是影响的行数。删除同理String deleteHql delete from User u where u.status :status; int deletedCount session.createQuery(deleteHql) .setParameter(status, inactive) .executeUpdate();这两条HQL执行时Hibernate会绕过一级缓存也不去加载实体对象直接生成UPDATE或DELETE的SQL发给数据库。这是个巨大优势你不再需要担心缓存膨胀也不再需要flush/clear。3.2 实操注意DML操作对缓存的影响这里我不得不强调一个很关键的坑DML风格的HQL操作不走一级缓存和二级缓存。意思就是它直接改数据库但Hibernate自己的缓存里可能还留着旧数据。举个例子你在一个事务里先批量把一堆用户的status改成“inactive”接着又用session.get(User.class, 1L)去查同一条记录。因为一级缓存里可能还有之前查过的这个对象你拿到的还是旧状态。哪怕一级缓存里没有二级缓存也可能给的是旧值。这个问题怎么破分两种情况如果确保该事务里不会再查询这些被修改的数据忽略即可提交后清缓存。如果事务里需要马上读最新数据那当前事务里修改之后就别用缓存读或者直接session.clear()把一级缓存清掉。若用了二级缓存还得调用sessionFactory.getCache().evictEntityRegion(User.class)来手动清掉整个实体区域。所以我现在的习惯是DML批量操作尽量放在事务的最后阶段也就是所有查询和业务判断都做完要收尾改库了再去执行它。省掉一堆缓存同步的麻烦。3.3 批量更新的另一种思路流式读取逐条更新有些场景比较特殊更新逻辑不是简单的一条HQL能表达的比如新值需要根据实体的多个属性计算出来或者更新前需要调用外部服务。这时候你还是得把实体捞回来处理。但请不要一次list()全拉回内存正确姿势是流式读取。Hibernate提供了scroll()方法可以在数据库层面游标式地一行行读取处理完一条更新一条Session session sessionFactory.openSession(); Transaction tx session.beginTransaction(); ScrollableResults results session.createQuery(from User u where u.age :age) .setParameter(age, 18) .setCacheMode(CacheMode.IGNORE) .scroll(ScrollMode.FORWARD_ONLY); int count 0; while (results.next()) { User user (User) results.get(0); user.setRemark(underage user); if (count % 20 0) { session.flush(); session.clear(); } } tx.commit(); session.close();这种方式的内存占用是恒定的不管表里有多少行它都是逐条处理。前提是你的数据库驱动要支持真正的流式读不能一次把结果集全拖回来。MySQL的话你是需要在JDBC连接URL上设置useCursorFetchtrue不然你以为你在“流式读取”实际上结果集已经全卡在内存里了等于没优化。这条路我走过很多次经验就一句话能在数据库层完成的工作不要在应用层反复横跳必须在应用层处理的请控制好缓存和批量窗口。4. 影响批处理性能的几个关键坑写代码是第一步性能调优是第二步。这些年我看过不少项目代码写法看着没啥毛病一跑大数据量就崩问题大概率出在下面这几个地方。4.1 最经典的一个坑batch_size配置无效有人配置了hibernate.jdbc.batch_size也用对了Session但实际观察数据库的prepared statement数量发现根本没有合并成批次。这种情况十有八九是主键生成策略的问题我前面已经提过GenerationType.IDENTITY会导致批处理失效。具体原因在于IDENTITY主键必须依赖数据库立即返回自增值否则后续的实体没法确定主键。所以Hibernate为了拿主键只能一条条插入批处理自然就废了。如果实在无法改掉主键策略那么就改用StatelessSession试试它有一定概率能绕过这个限制但依然不如SEQUENCE来得实在。另一个原因可能是没有设置hibernate.order_inserts。当你的循环里交替插入不同实体类型时不排序的话批处理会被打断。设了order_insertstrue后Hibernate会先把相同类型的INSERT排序再组合效果立竿见影。4.2 更新操作触发了不必要的字段更新默认情况下Hibernate更新一个实体时会把所有字段都放到UPDATE语句里哪怕你只改了其中一个属性。这个特性在单条更新时无所谓但在批量更新场景下会大大增加数据库的负载。解决办法是配置DynamicUpdate注解让Hibernate动态生成只包含变更字段的UPDATE语句。要注意这个注解生效的前提是你不能使用session.update()手动更新而是要让Hibernate自己通过脏检查机制触发的更新。Entity DynamicUpdate Table(name user) public class User { // ... }加了注解之后Hibernate在更新时就会比较当前实体与快照的差异只更新不同的列。但这里有个隐藏成本动态更新会略微增加更新时的快照比对开销。所以我的建议是这种注解只加在确实需要频繁批量更新的实体上不需要全员开。4.3 分页批量查询的正确打开方式批量操作不止是插入、更新和删除批量查询也是大头。很多新手写分页批量查询时直接用setFirstResult和setMaxResults。这在数据量小时没问题一旦数据量大比如翻到第50页这种写法就变成了“先查到50页之前的所有数据再丢弃前49页”性能极差。我推荐的做法是基于游标的批量查询也就是我前面提过的scroll()。如果要一次性取出全量数据做处理流式读取的性能是碾压式的好。如果确实要做Web端分页建议用上一页返回的某个排序字段的快照值来做条件过滤而不是纯粹依赖偏移量。举个例子如果按ID排序就记住上一页最后一条的ID下一页查询条件加上where id :lastId配合limit。这个方案在千万级数据下表 Hibernate批量操作实战：从JDBC批处理到StatelessSession的性能优化指南
最近在带团队做一个老项目的性能优化发现不少人一提到Hibernate就先皱眉说它“重”、说它“慢”甚至直接问“这玩意儿还有人用吗”。这话题我太熟了。Hibernate作为Java界最老牌的ORM框架确实有过一些历史包袱但只要你把它的批量操作玩明白性能完全能打甚至能在某些场景下比手写JDBC更稳。这篇东西我不打算给你念文档就当一个用了十几年Hibernate的老兵给你捋一捋批量操作到底是什么、怎么用出效果、有哪些绕不开的坑。尤其是那些真正在高并发、大数据量场景下踩过雷的同学这篇应该能帮你省不少调试时间。如果你是刚接触Hibernate不久也完全能看懂我会把背后的原理也讲透。1. Hibernate批量操作是什么为什么总有人卡在这里很多新人第一次遇到“批量操作”这个需求处理方式非常直观写个for循环把实体一个个session.save()或者session.update()等循环结束再统一提交事务。小数据量跑起来没什么感觉最多慢一点。但一旦数据量上了万级你就会发现性能断崖式下跌甚至直接OOM。1.1 核心概念不是“批量”而是“攒一批”Hibernate里的批量操作准确说不是“批量”这俩字的字面意思而是把一批小操作合并成更少的大操作减少数据库往返次数同时控制自家的一级缓存不要无限膨胀。举个例子你要往一张表里插入10万条记录。如果你傻乎乎地for循环插入Hibernate每插入一条都会先检查一级缓存Session级别的缓存再往数据库发一条INSERT同时把实体对象存放在缓存里。10万条实体全堆在Session里不光内存爆炸光是那10万次数据库往返就够你喝一壶。所以批量操作的核心就三个字攒批、清缓存、走底层。1.2 适用场景哪些需求必须要批量不是所有代码都需要用批量操作。我个人在实际项目里的经验下面这几种场景必须认真考虑批量方案否则早晚出事数据迁移和初始化比如把一个旧系统的数据导入新系统每天定时跑条数都是十万起步。批量状态更新比如订单系统里定时任务把所有超时未支付的订单批量标记为“已取消”。报表或者ETL类的批量写库从外部文件读取大量数据解析后写入业务表。需要同时更新或删除一整个集合的数据比如按某个条件批量清空无效记录。这些场景的共同点很明显数据量大操作类型单一且重复。这正是批量操作能发挥最大价值的地方。1.3 为什么“Hibernate还有人用吗”会成为一个问题这里我想先回应一下那个热搜词“Hibernate还有人用吗”。说实话这个问题本身反映出很多团队其实没把Hibernate用对。如果你只会用最简单的session.save()那确实会被MyBatis按在地上摩擦。但Hibernate真正擅长的地方在于对象状态管理和二级缓存体系当你需要做复杂的关联关系维护、多级缓存策略或者赶项目进度需要快速建模时Hibernate的开发效率还是碾压级的。批量操作就是Hibernate从“能用”到“用好”之间最关键的一道坎。跨过去了你就知道怎么控制它而不是被它拖累。2. 两种最常用的批量写入方案JDBC批处理与StatelessSession先聊写入。写入是批量操作里使用频率最高的一种。在Hibernate圈子批量写入的解决方案主要有两个方向JDBC批处理和StatelessSession。这两个方案各有脾气选错了你就会觉得“还是用MyBatis吧”。2.1 JDBC批处理配置与原理JDBC批处理是利用数据库底层的PreparedStatement.addBatch()和executeBatch()能力把多条SQL攒在一起发给数据库由数据库一次性执行。Hibernate本身不关闭这个通道但你需要主动告诉它开启批处理并且告诉我攒几条发一次。第一步配置一个关键参数hibernate.jdbc.batch_size。这个参数决定了Hibernate攒多少条SQL之后真正向数据库发送一次。我一般建议设成20到50之间经验值是3的倍数原因是很多数据库驱动比如Oracle内部默认按3条一组来绑定参数不是倍数容易浪费批次的容量。以100为例含义是每调用100次session.save()Hibernate才向数据库真正发送一次批量INSERT。中间99次的SQL都被本地攒起来了。这样一来数据库往返次数就直接少了两个数量级。还有几个配套参数我列个表给你参考参数名推荐值作用hibernate.jdbc.batch_size20~50攒多少条SQL再发送太大会消耗应用内存hibernate.order_insertstrue对INSERT按实体类型排序让同一类型的INSERT能合并成批次hibernate.order_updatestrue对UPDATE按实体类型排序减少更新时的死锁风险hibernate.jdbc.batch_versioned_datatrue允许对版本化数据使用批处理默认是关闭的order_inserts和order_updates这两个参数特别容易被忽略。如果你的代码里交替穿插着不同类型的实体操作不排序的话批处理会被拆散效果大打折扣。给它们设成true等于先给所有SQL排队同类归置在一起再发车。第二步编码时要主动刷缓存。JDBC批处理虽然解决了数据库往返问题但一级缓存膨胀的问题还在。所以你必须在循环里定期调用session.flush()和session.clear()。flush()是把攒着的SQL按批次发出去clear()是清空一级缓存释放内存。建议在每插入batch_size条后做一次flush和clear这样内存水位能控制得住。下面写一个标准的JDBC批处理插入代码你直接可以抄作业Session session sessionFactory.openSession(); Transaction tx session.beginTransaction(); int batchSize 30; for (int i 0; i 100000; i) { User user new User(); user.setName(user_ i); user.setAge(i % 100); session.save(user); if (i % batchSize 0) { // 攒够一批推给数据库同时清空一级缓存 session.flush(); session.clear(); } } tx.commit(); session.close();这个代码里最容易出错的地方就是flush和clear的时机。flush太频繁会降低攒批效果flush太晚又容易内存爆炸。我实践中的做法是以batch_size为步长每步flush一次clear一次。这样实体对象不会在Session里堆积。对了还有个小技巧插入操作最好给主键生成器加上GeneratedValue(strategy GenerationType.SEQUENCE)这类数据库侧生成策略。如果你用的是IDENTITY数据库为了拿到自增主键会强制立即执行INSERT导致批处理被静默跳过。这是个很隐蔽的坑网上很多帖子都没说清楚你在做批量插入时一定要检查主键策略。2.2 StatelessSession无缓存批处理方案JDBC批处理虽然快但一级缓存总像个“包袱”——要管、要清、不能太满。这时候就该请出StatelessSession了。顾名思义无状态Session它完全不维护一级缓存也不管实体的状态管理实体对象进来直接就转换成SQL执行没有快照比对没有懒加载关联关系一切从简。使用方式上它和Session很像都是从SessionFactory获取。区别在于它没有flush()、没有clear()也不支持saveOrUpdate()这种级联操作就是最朴素的insert()、update()、delete()。StatelessSession session sessionFactory.openStatelessSession(); Transaction tx session.beginTransaction(); for (int i 0; i 100000; i) { User user new User(); user.setName(user_ i); user.setAge(i % 100); session.insert(user); } tx.commit(); session.close();注意虽然它叫“Stateless”但它身上还是可以配置hibernate.jdbc.batch_size底层依然会走JDBC批处理。所以官方其实推荐用StatelessSession来做纯批量写入启动快、内存占用低糙快猛。StatelessSession的代价就是失去了ORM的核心能力。它不会维护持久化上下文意味着你没法在同一个事务里先插一个订单再通过session.get()把它取回来继续操作因为这些实体根本没有被跟踪。所以它适合的场景是纯写入、纯删除、或者纯更新尤其是那种数据从文件或消息队列过来不需要回查的场景。2.3 二者对比什么时候选哪个我来整理一个对比表格方便你一眼看懂对比项Session JDBC批处理StatelessSession维护一级缓存是需手动flush/clear否零缓存支持级联操作支持不支持支持懒加载支持不支持内存占用高需小心溢出低几乎无累积适合场景业务实体关联复杂但量不大海量一次性写入、迁移批处理支持支持需配置batch_size支持同样需配置个人实践经验是如果单次事务里要处理的数据量超过1万条且实体对象不与其他实体有关联关系优先考虑StatelessSession。如果实体有关联、有级联、需要对象状态管理但又想提速则用Session加JDBC批处理。3. 批量更新与删除HQL的DML风格操作写入讲完了再来聊更新和删除。很多人批量更新用的方法很笨先session.createQuery(...).list()查出一大堆实体然后for循环改属性再让Hibernate自动更新。我对这种写法只有一句话形容又慢又要命。3.1 两条查询干掉一万次更新update/delete HQLHibernate里提供了一个“不讲武德”的批量更新方式直接在HQL里执行update或delete语句语法上几乎和SQL一致。它本质上走的是JDBC底层的batch能力但不用你把实体捞回内存再挨个改直接在数据库层面把事干了。典型的用法如下Session session sessionFactory.openSession(); Transaction tx session.beginTransaction(); String hql update User u set u.status :newStatus where u.age :age; int updatedCount session.createQuery(hql) .setParameter(newStatus, inactive) .setParameter(age, 18) .executeUpdate(); tx.commit(); session.close();就这么一条HQL你的批处理需求直接解决了。返回的updatedCount就是影响的行数。删除同理String deleteHql delete from User u where u.status :status; int deletedCount session.createQuery(deleteHql) .setParameter(status, inactive) .executeUpdate();这两条HQL执行时Hibernate会绕过一级缓存也不去加载实体对象直接生成UPDATE或DELETE的SQL发给数据库。这是个巨大优势你不再需要担心缓存膨胀也不再需要flush/clear。3.2 实操注意DML操作对缓存的影响这里我不得不强调一个很关键的坑DML风格的HQL操作不走一级缓存和二级缓存。意思就是它直接改数据库但Hibernate自己的缓存里可能还留着旧数据。举个例子你在一个事务里先批量把一堆用户的status改成“inactive”接着又用session.get(User.class, 1L)去查同一条记录。因为一级缓存里可能还有之前查过的这个对象你拿到的还是旧状态。哪怕一级缓存里没有二级缓存也可能给的是旧值。这个问题怎么破分两种情况如果确保该事务里不会再查询这些被修改的数据忽略即可提交后清缓存。如果事务里需要马上读最新数据那当前事务里修改之后就别用缓存读或者直接session.clear()把一级缓存清掉。若用了二级缓存还得调用sessionFactory.getCache().evictEntityRegion(User.class)来手动清掉整个实体区域。所以我现在的习惯是DML批量操作尽量放在事务的最后阶段也就是所有查询和业务判断都做完要收尾改库了再去执行它。省掉一堆缓存同步的麻烦。3.3 批量更新的另一种思路流式读取逐条更新有些场景比较特殊更新逻辑不是简单的一条HQL能表达的比如新值需要根据实体的多个属性计算出来或者更新前需要调用外部服务。这时候你还是得把实体捞回来处理。但请不要一次list()全拉回内存正确姿势是流式读取。Hibernate提供了scroll()方法可以在数据库层面游标式地一行行读取处理完一条更新一条Session session sessionFactory.openSession(); Transaction tx session.beginTransaction(); ScrollableResults results session.createQuery(from User u where u.age :age) .setParameter(age, 18) .setCacheMode(CacheMode.IGNORE) .scroll(ScrollMode.FORWARD_ONLY); int count 0; while (results.next()) { User user (User) results.get(0); user.setRemark(underage user); if (count % 20 0) { session.flush(); session.clear(); } } tx.commit(); session.close();这种方式的内存占用是恒定的不管表里有多少行它都是逐条处理。前提是你的数据库驱动要支持真正的流式读不能一次把结果集全拖回来。MySQL的话你是需要在JDBC连接URL上设置useCursorFetchtrue不然你以为你在“流式读取”实际上结果集已经全卡在内存里了等于没优化。这条路我走过很多次经验就一句话能在数据库层完成的工作不要在应用层反复横跳必须在应用层处理的请控制好缓存和批量窗口。4. 影响批处理性能的几个关键坑写代码是第一步性能调优是第二步。这些年我看过不少项目代码写法看着没啥毛病一跑大数据量就崩问题大概率出在下面这几个地方。4.1 最经典的一个坑batch_size配置无效有人配置了hibernate.jdbc.batch_size也用对了Session但实际观察数据库的prepared statement数量发现根本没有合并成批次。这种情况十有八九是主键生成策略的问题我前面已经提过GenerationType.IDENTITY会导致批处理失效。具体原因在于IDENTITY主键必须依赖数据库立即返回自增值否则后续的实体没法确定主键。所以Hibernate为了拿主键只能一条条插入批处理自然就废了。如果实在无法改掉主键策略那么就改用StatelessSession试试它有一定概率能绕过这个限制但依然不如SEQUENCE来得实在。另一个原因可能是没有设置hibernate.order_inserts。当你的循环里交替插入不同实体类型时不排序的话批处理会被打断。设了order_insertstrue后Hibernate会先把相同类型的INSERT排序再组合效果立竿见影。4.2 更新操作触发了不必要的字段更新默认情况下Hibernate更新一个实体时会把所有字段都放到UPDATE语句里哪怕你只改了其中一个属性。这个特性在单条更新时无所谓但在批量更新场景下会大大增加数据库的负载。解决办法是配置DynamicUpdate注解让Hibernate动态生成只包含变更字段的UPDATE语句。要注意这个注解生效的前提是你不能使用session.update()手动更新而是要让Hibernate自己通过脏检查机制触发的更新。Entity DynamicUpdate Table(name user) public class User { // ... }加了注解之后Hibernate在更新时就会比较当前实体与快照的差异只更新不同的列。但这里有个隐藏成本动态更新会略微增加更新时的快照比对开销。所以我的建议是这种注解只加在确实需要频繁批量更新的实体上不需要全员开。4.3 分页批量查询的正确打开方式批量操作不止是插入、更新和删除批量查询也是大头。很多新手写分页批量查询时直接用setFirstResult和setMaxResults。这在数据量小时没问题一旦数据量大比如翻到第50页这种写法就变成了“先查到50页之前的所有数据再丢弃前49页”性能极差。我推荐的做法是基于游标的批量查询也就是我前面提过的scroll()。如果要一次性取出全量数据做处理流式读取的性能是碾压式的好。如果确实要做Web端分页建议用上一页返回的某个排序字段的快照值来做条件过滤而不是纯粹依赖偏移量。举个例子如果按ID排序就记住上一页最后一条的ID下一页查询条件加上where id :lastId配合limit。这个方案在千万级数据下表