JDBC / Hibernate获取大小和内存问题

Question

在调查了一下工作后，我注意到我正在使用的应用程序正在使用默认的提取大小（根据我的知识，Oracle为10）。问题在于，在大多数情况下，用户获取大量数据（范围从几千到甚至几十万），默认的10确实是一个巨大的瓶颈。

因此，这里明显的结论是使获取大小更大。起初我正在考虑将默认值设置为100并将其提升为1000以进行多次查询。但后来我在网上读到默认值太小以防止内存问题（即当JVM堆无法处理如此多的数据时），我应该担心它吗？

我还没有看到任何进一步的解释。是否意味着更大的提取大小意味着在获取结果集时会产生更多开销？或者它们只是意味着默认情况下我可以获取10条记录然后GC它们并获取另外10条等等（而假设一次获取10000条会导致OutOfMemory异常）？在这种情况下，我真的不在乎，因为我需要记忆中的所有记录。在前一种情况下（更大的结果集意味着更大的内存开销）我想我应该先加载测试它。

Answer 1

通过设置提取大小， 冒着OutOfMemoryError的风险。

无论如何，你需要所有这些记录的事实可能是不合理的。您需要更多机会获得返回的ResultSet所反映的实体 ...将获取大小设置为10000意味着您正在堆积由JDBC类表示的10000条记录。当然，您不会通过您的应用程序传递这些内容。您首先将它们转换为您最喜欢的业务逻辑实体，然后将它们交给您的业务逻辑执行器。这样，只要JDBC获取下一个获取批量，就会为GC提供第一个获取批量的记录。

通常，由于前面提到的内存威胁，这次转换完全是一堆完成的。

但有一件事你是绝对正确的：在调整之前，你应该用明确定义的要求测试性能。

Answer 2

  

因此，这里明显的结论是使获取大小更大。

也许一个同样明显的结论应该是：“让我们看看我们是否可以减少用户带回来的对象数量。”当Google返回结果时，它会以25或50的批次进行分类，最大可能被您视为有用。如果您的用户带回了数千个对象，也许您需要考虑如何减少这些对象。数据库可以做更多的工作吗？是否有其他操作可以编写以消除其中的一些对象？物体本身能更聪明吗？