在这里我特别进行测试的是ArrayList相对于LinkedList的另一个优点，即预先确定集合大小的能力。具体地说，创建ArrayList的时候允许指定一个具体的大小(例如，在测试中ArrayList可以创建为拥有100个元素的容量)，从而避免所有随着元素增多而增加集合规模的开销。表1括号中的数字显示了预先确定集合大小时性能的提高程度。LinkedList(直到 SDK 1.3)不能预先确定大小。
此外，ArrayList只生成少量的需要进行垃圾收集的对象，即，用来保存元素的内部数组对象，以及每次ArrayList容量不足需要进行扩展时创建的附加内部数组对象。LinkedList不管可能出现的任何删除操作，都为每一个插入操作生成一个节点对象。因此，LinkedList会给垃圾收集器带来相当多的工作。考虑到这些因素，对于任何中小规模的集合，我会选择使用ArrayList而不是LinkedList。 表2：构造一个大型集合(10,000个元素)
1.2 JVM1.3 JVMHotSpot 2.0 JVM
总是插入到ArrayList的开头7773%7537%7500%
总是插入到LinkedList的开头100%90.34%65.6%
总是插入到ArrayList的中间3318%3412%3121%
总是插入到LinkedList的中间26264%14315%14209%
总是插入到ArrayList的末尾41.4%41.2%37.5%
总是插入到LinkedList的末尾66.4%73.9%61.7%
表2显示了大规模集合的测试结果。可以看到，在出现大规模插入操作的时候，我们开始遭遇严厉的性能惩罚。正如我们前面分析类的实现所得到的结果，对于LinkedList来说最差的情形出现在把元素插入到集合中间时。另外我们还可以看到，与使用ArrayList时把元素插入到集合开头的最差性能相比，使用LinkedList时把元素插入到集合中间的性能更差一些。和这两种性能最差的情况相比，把元素插入到ArrayList中间的性能显然要好得多。
总地看来，ArrayList再一次在大多数情形下表现出更好的性能，包括根据索引把元素插入到随机位置的情形。如果你总是要把元素插入到集合中靠前的位置，LinkedList具有更好的性能;然而，此时你可以利用一个反向的ArrayList得到更好的性能，即，使用一个专用的实现，或者通过[size -index]映射翻转索引在集合中的位置。 表3：构造一个超大集合(1,000,000个元素)
1.2 JVM1.3 JVMHotSpot 2.0 JVM
总是插入到ArrayList的开头太长太长太长
总是插入到LinkedList的开头100%179.5%144.1%
总是插入到ArrayList的中间太长太长太长
总是插入到LinkedList的中间太长太长太长
总是插入到ArrayList的末尾38.3%47.7%42.9%
总是插入到LinkedList的末尾65.1%161.5%139.9%
表3显示了超大集合的测试结果，从该表可以得出的结论与表2非常相似。然而，表3强调的是，超大集合要求数据、集合类型、数据处理算法之间的恰到好处的配合
文章来源于领测软件测试网 https://www.ltesting.net/
