成本將列表到內存

Question

這是比較昂貴和多少：

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

比。

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

我想我真正的問題是，將大量清單放到內存中是否昂貴？還是足夠聰明，只能得到它所需要的那麼大？添加時較小，但搜索時較大。

Answer 1

很明顯，在內存中獲取大名單比獲取較小的名單更昂貴。 實際上，成本因素取決於您的物體的大小，並取決於initial heap size。事實上，當JVM沒有更多的內存時，它的堆大小從它的Xms參數擴展到它的Xmx參數。

但是，只有getMyBigList方法創建對象時纔是如此。如果這些對象已經加載到內存中，這種方法只會在內存中加載一個100 000個引用的列表，而這個引用不會超過幾Mb。

在這種情況下，您的限制因素不會是JVM的內存分配，而是您用來加載該列表的方法。

它們是從網絡加載的嗎？帶寬就是限制。

它們是否從磁性硬盤驅動器加載？帶寬就是限制。

Answer 2

我想你問是否調整列表是一個昂貴的操作。

這個問題的答案是，這取決於List實現，例如作爲ArrayList實現：

每個ArrayList實例都有一個容量。容量是用於存儲列表中元素的數組大小。它總是至少與列表大小一樣大。隨着元素被添加到ArrayList，其容量會自動增長。增長政策的細節並未超出添加元素具有不變攤銷時間成本的事實。

在使用ensureCapacity操作添加大量元素之前，應用程序可以增加ArrayList實例的容量。這可能會減少增量重新分配的數量。

Answer 3

將一個大型列表放入內存是否昂貴？還是足夠聰明，只能得到它所需要的那麼大？添加時較小，但搜索時較大。

什麼是「它」？ List是一個接口。如何「聰明」由getMyBigList()返回的對象完全依賴於該方法的實現以及它返回的對象的類。從理論上講，它可能是某種延遲加載「智能」實現。很可能，事實並非如此。