据我所知，到目前为止，无状态会话在使用批处理时是首选，因为它只会分离执行该过程的对象，因此持久化上下文和缓存将是免费的，因此批处理是空闲的情况，通常称为普通JDBC查询引擎，查询立即转换为SQL查询。 参考自：https://stackoverflow.com/a/14174403/1460591
另一方面，我了解到本机查询的作用相同，我看到的一个区别是无状态会话可以将结果映射到实体，在显式提供mapper之前，Native查询不会这样做。
那么还有另一个不同之处，从性能的角度来看，在批量处理时更好吗？
答案 0 :(得分：3)
如果批处理是指通过SQL查询本身修改数据库服务器中的实体（例如UPDATE things SET daily_quota=15），那么本机SQL更快。但是，在这种情况下，您不会加载任何实体，因此这似乎与您的问题无关。
如果通过批处理来表示修改程序中的实体（例如加载所有Thing实例，请将dailyQuota属性修改为15并编写更新，然后您将需要无状态会话
使用本机查询检索对象并不能为您提供任何修改对象的机制。您仍然需要将其合并回持久性上下文并刷新这些更改。一旦你这样做（假设你没有无状态会话）那么它将使用经典的变化检测＆amp;缓存保持刷新机制。
另一方面，无状态会话为您提供了一种方法来修改程序中的实体，而无需强制ORM层完成缓慢的变化检测过程。
答案 1 :(得分：2)
在进入Hibernate无状态会话之前你好我会认真问自己为什么需要它。首先，您已经了解了使用无状态会话时的想法和功能。
即使hibernate会话占用大量内存，在大多数情况下仍可以获得不错的性能。如果你不能这样做，你的代码中可能还有其他问题。
我想强调的是，无状态会话不会级联持久化，合并等操作。这将消除您通过休眠通常会收到的authomatization的重要元素。从长期来看，这可能会影响您的代码的可维护性和易于更改。
由于在开发方面没有代码是完全静态的，所以新功能有时会出现需要改变的东西......等等......乍一看，批处理可能会变得非常大。在这种情况下，您手边的功能数量非常重要。
我认为，如果你真的处于绝望的性能需求中，那么就存储库或其他东西而言，你应该明确地将持久性与业务层分开。如果有必要，你只需编写一些基于SQL的纯存储库或尽可能接近本机sql的东西，例如JOOQL。
在我的职业生涯中，我已经看到一些非常复杂的批次写入正常的休眠会话时，在考虑SLA时运行良好。我有一个反复的例子，一个批处理运行超过2000次分布式事务，超过16 cpus写入Hibernate与正常会话。
我需要大量性能的极少数情况我会使用JOQL，因为它是最接近SQL的维护ORM关系的东西。