Java 在内存方面，大阵列还是多阵列更好、更高效？

我正在开发的应用程序，用户可以模拟测试并离线回答。我有一个软件，可以从我的数据库中获取数据（问题、备选方案、问题类型等），并将它们转换成一个数组

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

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

我想用什么

---

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

老实说，1000不是一个大尺寸，但它关系到元素的大小

然而，在将来，您的条目大小将增加，所以您肯定不希望每次都更改逻辑。因此，您必须设计高效的内容，这对于不断增长的数据也应该是有益的

内存问题-如果您将所有数据存储在一个数组或10个数组中，则这两个数组将占用大致相同的内存量（非常小的差异）， 但如果您有10个阵列，那么管理可能会很困难，随着需求的增长，您可能会面临更复杂的问题

---

我可以建议您使用单阵列，这对管理非常有用。你也可以考虑链接列表，这对于更快的搜索结果很有帮助。

你需要考虑的三种效率“

”

• 内存效率；即最小化RAM利用率
• CPU效率
• 程序员效率；即最大限度地减少在编写、编写测试用例、调试和维护代码上花费的宝贵时间

请注意，上述标准相互矛盾

内存效率 Java中引用N数组的内存大小（字节），由

  N * reference_size + array_header_size + padding

其中：

• reference\u size

  是引用的大小，以字节为单位（通常为4或8）

• array\u header\u size

  通常为12字节

• 填充

  大于或等于零，并且小于堆节点大小粒度

数组本身也有一个唯一的引用，它必须保存在内存中的某个地方

因此，如果您将一个大数组拆分为M个较小的数组，您将使用至少

（M-1）*16个额外的RAM字节，甚至更多。另一方面，我们在这里讨论的是字节，而不是千字节或兆字节。因此这并不重要

CPU效率
这是很难预测的。CPU利用率的影响很大程度上取决于你对阵列做了什么，以及你是如何做的

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

如果要在数组中搜索某个对象，则必须搜索的数组越大（平均而言），搜索所需的时间就越长。但是，如果将大型数组拆分为较小的数组，这并不一定有帮助……除非您事先知道要搜索哪个较小的数组

程序员效率
如果使用多个数组而不是一个数组，可能会使代码更加复杂。更复杂的代码意味着程序员在应用程序开发和维护生命周期的所有阶段都要付出更多的努力。很难量化需要付出多少额外努力。然而，程序员的努力意味着成本（支付工资）和时间（截止日期、上市时间等），这可能会超过内存和CPU方面的任何小节约

可伸缩性
你说：

有些人说1000个条目不算太多，所以我想我还是选择一个大的数组。什么会太大？10k，100k

同样，这取决于上下文。实际上，一个包含100K个X实例的数组所使用的内存在很大程度上取决于X的平均大小。您很可能会耗尽内存来表示X实例而不是数组

因此，如果您希望应用程序无限期地扩展，您可能应该更改体系结构，以便它根据需要从数据库获取问题/答案，而不是在启动时将它们全部加载到内存中

过早优化
唐纳德·克努特（Donald Knuth）经常被（错误地）引用说：

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

他指出的是，程序员倾向于优化不需要优化的东西，或者根据错误的直觉将精力花在优化错误的代码区域上

我的建议如下：


不要过早地进行细粒度优化。（这并不意味着您应该忽略设计和编码阶段的效率关注，但我的建议是只考虑主要问题，例如算法的复杂性、API和数据库查询的粒度等，尤其是以后要费力费力的事情。）

如果您进行优化，请科学地进行优化：


使用基准来衡量绩效
使用探查器查找性能热点，并将精力集中在这些热点上
使用基准测试来查看优化是否有改进，并放弃没有帮助的优化


设定一些现实的目标（或时间限制）