一个大数组还是多个数组，哪个是更好，更有效的内存存储方式？

我正在使用的应用程序，用户可以在其中模拟测试并脱机答复它们。我有一个软件可以从数据库中获取数据（问题，替代方案，问题类型等）并将其转换为数组。

我不知道哪个是最有效的（在内存方面）：创建一个包含所有问题的大数组的对象，或者创建每个数组的单独对象（例如，针对每个主题）或在其中创建多个数组同一对象。可以创建一个内部包含大约1000个数组的数组吗？还是最好将其拆分成10个内部包含100个数组的数组？

PS：在测试期间，我将只使用阵列中的30个项目，因此我将从大型阵列（或多个阵列）中获取条目，并将它们添加到将要创建的30个小型条目数组中根据用户的输入。

我想使用的东西

我想要一个大型数组，因为对我而言，排序和创建随机测试会更容易，有人说1000个条目不是太多，所以我认为我会坚持使用大型数组。太大了吗？ 10k，100k？

说实话，1000并不是很大，但是元素的大小很重要。

但是，将来您的条目大小会增加，因此，您绝对不想每次都更改逻辑。因此，您必须设计高效的事物，这对于增长数据也应是富有成果的。

有关内存的问题-如果将所有数据存储在一个阵列或10个阵列中，则两者都将占用几乎相同的内存量（差异很小），但是，如果您有10个Array，则管理可能会很困难，随着需求的增长，您将面临更多的复杂性。

我建议您使用单个阵列，这对管理非常有用。您也可以考虑使用LinkedList，这对于更快的搜索结果将非常有用。

您需要考虑三种效率”

请注意，以上条件相互矛盾。

内存效率

Java中引用N的数组的内存大小（以字节为单位）

  N * reference_size + array_header_size + padding

其中：

数组本身还有一个唯一的引用，该引用必须保存在内存中的某个位置。

因此，如果将一个大阵列拆分为M个较小的阵列，则将至少使用(M - 1) * 16个额外的RAM字节，甚至可能更多。另一方面，我们在这里谈论的是字节，而不是千字节或兆字节。因此，这几乎没有意义。

这很难预测。 CPU利用率的影响将在很大程度上取决于您对阵列的处理方式以及处理方式。

如果只是在数组下标（索引），则该操作不取决于数组大小。但是，如果您有多个数组（例如，一个数组的数组），那么确定下标中的哪个数组将产生额外的开销。

如果要在数组中搜索某些内容，则搜索的数组越大，平均花费的时间就越长。但是，如果您将一个大型数组拆分为多个较小的数组，则不一定有帮助……除非您事先知道要搜索哪个较小的数组。

如果使用多个数组而不是一个数组，则可能会使代码更复杂。更复杂的代码意味着在应用程序开发和维护生命周期的所有阶段中，程序员都要付出更多的努力。很难量化所涉及的额外工作量。但是，程序员的努力意味着成本（支付薪水）和时间（截止日期，上市时间等），并且这可能超过任何少量的内存和CPU节省。

您说：

有人说1000个条目不是太多，所以我认为我会坚持很多。太大了吗？ 10k，100k？

再次，这取决于上下文。实际上，用于100K个X实例数组的内存在很大程度上取决于X的平均大小。您很可能会用光内存来表示X实例而不是数组。

因此，如果您希望应用程序无限期扩展，则可能应该更改架构，以使其按需从数据库中获取问题/答案，而不是一开始就将它们全部加载到内存中。上。

唐纳德·努斯经常被（mis-）引用¹的话：

“过早的优化是万恶之源。”

他所指出的是，程序员倾向于优化那些并不需要进行优化的事情，或者倾向于根据错误的直觉来优化代码的错误区域。

我对此的建议如下：

不要太早进行细粒度的优化。（这并不意味着您应该在设计和编码阶段忽略效率问题，但是我的建议是仅考虑主要问题；例如算法的复杂性，API的粒度和数据库查询等等。尤其是事情以后需要付出很多努力。）
如果以及何时进行优化，请科学地进行：
- 使用基准来衡量性能。
- 使用探查器查找性能热点并将您的精力集中于这些热点。
- 使用基准测试来查看优化是否有所改善，并放弃无济于事的优化。
为优化设置一些现实的目标（或时间限制），并在达到目标时停止。

^{1-完整的报价更加细微。查一下实际上，Knuth自己引用了Tony Hoare。要对此进行更深入的探索，请参见https://ubiquity.acm.org/article.cfm?id=1513451}