Question

哪个更贵，多少钱：

List<cards> cardList = getMyList(small);//returns a list of 100 elements
cardList.add(card);

Vs以上。

List<cards> cardList = getMyList(big);//returns a list of 100,000 elements
cardList.add(card);

我想我的真正问题是，将大型列表带入内存是否昂贵？或者列表足够聪明，只能达到它需要的大小？添加时较小但搜索时较大。

Answer 1

很明显，在内存中获取一个大的列表比获得一个更小的列表更昂贵。实际上，成本因素取决于对象的大小，以及initial heap size。实际上，当JVM没有更多内存时，它的堆大小从其Xms参数增加到其Xmx参数。

但是，只有getMyBigList方法创建对象时才会出现这种情况。如果这些对象已经加载到内存中，则此方法只会在内存中加载一个包含10万个引用的列表，这样不会超过几Mb。

在这种情况下，您的限制因素不是JVM的内存分配，而是您用来加载该列表的方法。

他们是从网络加载的吗？然后是带宽限制。

它们是从磁性硬盘驱动器加载的吗？然后是带宽限制。

Answer 2

我想你问的是，调整列表大小是否是一项昂贵的操作。

答案是，它取决于List实现，例如ArrayList实现：

每个ArrayList实例都有一个容量。容量是用于存储列表中元素的数组的大小。它始终至少与列表大小一样大。当元素添加到ArrayList时，其容量会自动增加。除了添加元素具有恒定的摊销时间成本这一事实之外，未指定增长政策的细节。

应用程序可以在使用ensureCapacity操作添加大量元素之前增加ArrayList实例的容量。这可能会减少增量重新分配的数量。

Answer 3

将大型列表带入内存是否昂贵？或者列表足够聪明，只能达到它需要的大小？添加时较小但搜索时较大。

什么是“它”？ List是一个界面。 getMyBigList()返回的对象的“智能”程度完全取决于该方法的实现以及它返回的对象的类。从理论上讲，它可能是某种延迟加载“智能”实现。最有可能的是，它不是。

将列表带入内存的成本

3 个答案: