|
SDK提供了有序集合接口java.util.List的几种实现，其中三种最为人们熟知的是Vector、ArrayList和LinkedList。有关这些List类的性能差别是一个经常被问及的问题。在这篇文章中，我要探讨的就是LinkedList和Vector/ArrayList之间的性能差异。
为全面分析这些类之间的性能差异，我们必须知道它们的实现方法。因此，接下来我首先从性能的角度出发，简要介绍这些类的实现特点。
一、Vector和ArrayList的实现
Vector和ArrayList都带有一个底层的Object[]数组，这个Object[]数组用来保存元素。通过索引访问元素时，只需简单地通过索引访问内部数组的元素：
|
public Object get(int
index)
{ // 首先检查index是否合法...此处不显示这部分代码
return
elementData[index]; }
|
内部数组可以大于Vector/ArrayList对象拥有元素的数量，两者的差值作为剩余空间，;便实现快速添加新元素。有了剩余空间，添加元素变得非常简单，只需把新的元素保存到内部数组中的一个空余的位置，然后为新的空余位置增加索引值：
|
public boolean
add(Object o)
{ ensureCapacity(size + 1); // 稍后介绍
elementData[size++] = o; return true;
// List.add(Object) 的返回值 }
|
把元素插入集合中任意指定的位置（而不是集合的末尾）略微复杂一点：插入点之上的所有数组元素都必须向前移动一个位置，然后才能进行赋值：
|
public void add(int
index, Object element) {
// 首先检查index是否合法...此处不显示这部分代码
ensureCapacity(size+1);
System.arraycopy(elementData, index, elementData,
index + 1,
size - index);
elementData[index] = element;
size++;
}
|
剩余空间被用光时，如果需要加入更多的元素，Vector/ArrayList对象必须用一个更大的新数组替换其内部Object[]数组，把所有的数组元素复制到新的数组。根据SDK版本的不同，新的数组要比原来的大50%或者100%（下面显示的代码把数组扩大100%）：
|
public void
ensureCapacity(int minCapacity) {
int oldCapacity = elementData.length;
if (minCapacity > oldCapacity) {
Object oldData[] = elementData;
int newCapacity = Math.max(oldCapacity * 2,
minCapacity);
elementData = new Object[newCapacity];
System.arraycopy(oldData, 0, elementData, 0, size);
}
}
|
Vector类和ArrayList类的主要不同之处在于同步。除了两个只用于串行化的方法，没有一个ArrayList的方法具有同步执行的能力；相反，Vector的大多数方法具有同步能力，或直接或间接。因此，Vector是线程安全的，但ArrayList不是。这使得ArrayList要比Vector快速。对于一些最新的JVM，两个类在速度上的差异可以忽略不计：严格地说，对于这些JVM，这两个类在速度上的差异小于比较这些类性能的测试所显示的时间差异。
通过索引访问和更新元素时，Vector和ArrayList的实现有着卓越的性能，因为不存在除范围检查之外的其他开销。除非内部数组空间耗尽必须进行扩展，否则，向列表的末尾添加元素或者从列表的末尾删除元素时，都同样有着优秀的性能。插入元素和删除元素总是要进行数组复制（当数组先必须进行扩展时，需要两次复制）。被复制元素的数量和[size-index]成比例，即和插入/删除点到集合中最后索引位置之间的距离成比例。对于插入操作，把元素插入到集合最前面（索引0）时性能最差，插入到集合最后面时（最后一个现有元素之后）时性能最好。随着集合规模的增大，数组复制的开销也迅速增加，因为每次插入操作必须复制的元素数量增加了。
二、LinkedList的实现
LinkedList通过一个双向链接的节点列表实现。要通过索引访问元素，你必须查找所有节点，直至找到目标节点：
|
public Object
get(intindex) {
// 首先检查index是否合法...此处不显示这部分代码
Entry e = header; // 开始节点
//
向前或者向后查找，具体由哪一个方向距离较
// 近决定
if (index < size/2) {
for (int i = 0; i <= index; i++)
e = e.next;
} else {
for (int i = size; i > index; i--)
e = e.previous;
}
return e;
}
|
把元素插入列表很简单：找到指定索引的节点，然后紧靠该节点之前插入一个新节点：
|
public void add(int
index, Object element) {
// 首先检查index是否合法...此处不显示这部分代码
Entry e = header; // starting node
//
向前或者向后查找，具体由哪一个方向距离较
// 近决定
if (index < size/2) {
for (int i = 0; i <= index; i++)
e = e.next;
} else {
for (int i = size; i > index; i--)
e = e.previous;
}
Entry newEntry = new Entry(element, e, e.previous);
newEntry.previous.next = newEntry;
newEntry.next.previous = newEntry;
size++;
}
|
线程安全的LinkedList和其他集合
如果要从Java SDK得到一个线程安全的LinkedList，你可以利用一个同步封装器从Collections.synchronizedList(List)得到一个。然而，使用同步封装器相当于加入了一个间接层，它会带来昂贵的性能代价。当封装器把调用传递给被封装的方法时，每一个方法都需要增加一次额外的方法调用，经过同步封装器封装的方法会比未经封装的方法慢二到三倍。对于象搜索之类的复杂操作，这种间接调用所带来的开销不是很突出；但对于比较简单的方法，比如访问功能或者更新功能，这种开销可能对性能造成严重的影响。
这意味着，和Vector相比，经过同步封装的LinkedList在性能上处于显著的劣势，因为Vector不需要为了线程安全而进行任何额外的间接调用。如果你想要有一个线程安全的LinkedList，你可以复制LinkedList类并让几个必要的方法同步，这样你可以得到一个速度更快的实现。对于所有其它集合类，这一点都同样有效：只有List和Map具有高效的线程安全实现（分别是Vector和Hashtable类）。有趣的是，这两个高效的线程安全类的存在只是为了向后兼容，而不是出于性能上的考虑。
对于通过索引访问和更新元素，LinkedList实现的性能开销略大一点，因为访问任意一个索引都要求跨越多个节点。插入元素时除了有跨越多个节点的性能开销之外，还要有另外一个开销，即创建节点对象的开销。在优势方面，LinkedList实现的插入和删除操作没有其他开销，因此，插入-删除开销几乎完全依赖于插入-删除点离集合末尾的远近。
三、性能测试
这些类有许多不同的功能可以进行测试。LinkedList应用比较频繁，因为人们认为它在随机插入和删除操作时具有较好的性能。所以，下面我分析的重点将是插入操作的性能，即，构造集合。我测试并比较了LinkedList和ArrayList，因为这两者都是非同步的。
插入操作的速度主要由集合的大小和元素插入的位置决定。当插入点的位置在集合的两端和中间时，最差的插入性能和最好的插入性能都有机会出现。因此，我选择了三个插入位置（集合的开头、末尾和中间），三种典型的集合大小：中等（100个元素），大型（10,000个元素），超大型（1,000,000个元素）。
在本文的测试中，我使用的是JAVA SDK 1.2.0和1.3.0系列的SUN JVM。此外，我还用HOTSPOT
JVM 2.0进行了测试，这个版本可以在1.3.0 SDK找到。在下面的表格中，各个测量得到的时间都以其中一次SDK
1.2 VM上的测试时间（表格中显示为100%的单元）为基准显示。测试期间使用了默认的JVM配置，即启用了JIT编译，因此对于所有JVM，堆空间都必须进行扩展，以避免内存溢出错误。表格中记录的时间是多次测试的平均时间。为了避免垃圾收集的影响，在各次测试之间我强制进行了完全的内存清理（参见测试源代码了解详情）。磁盘监测确保磁盘分页不会在测试过程中出现（任何测试，如果它显示出严重的磁盘分页操作，则被丢弃）。所有显示出数秒应答时间的速度太慢的测试都重复进行，直至记录到一个明显合理的时间。
|
表1：构造一个中等大小的集合（100个元素）。括号中的数字针对预先确定大小的集合。
|
|
|
1.2 JVM
|
1.3 JVM
|
HotSpot 2.0 JVM
|
|
总是插入到ArrayList的开头
|
100% (48.0%)
|
184.9% (152.0%)
|
108.0% (66.7%)
|
|
总是插入到LinkedList的开头
|
135.5%
|
109.1%
|
85.3%
|
|
总是插入到ArrayList的中间
|
130.0% (40.6%)
|
187.4% (158.0%)
|
84.7% (46.0%)
|
|
总是插入到LinkedList的中间
|
174.0%
|
135.0%
|
102.3%
|
|
总是插入到ArrayList的末尾
|
63.3% (20.7%)
|
65.9% (25.0%)
|
60.3% (29.3%)
|
|
总是插入到LinkedList的末尾
|
106.7%
|
86.3%
|
80.3%
|
对于规模较小的集合，ArrayList和LinkedList的性能很接近。当元素插入到集合的末尾时，即追加元素时，ArrayList的性能出现了突变。然而，追加元素是ArrayList特别为其优化的一个操作：如果你只想要一个固定大小的静态集合，Java数组（例如Object[]）比任何集合对象都具有更好的性能。除了追加操作，测量得到的时间数据差别不是很大，它们反映了各个JVM的优化程度，而不是其他什么东西。
例如，对于把元素插入到集合的开始位置来说（表1的前两行），HotSpot
2.0 JVM加LinkedList具有最好的性能（85.3%），处于第二位的是
1.2 JVM加ArrayList（100%）。这两个结果显示出，1.2中简单的JIT编译器在执行迭代和复制数组等简单的操作时具有很高的效率。在HotSpot中复杂的JVM加上优化的编译器能够改进复杂操作的性能，比如对象创建（创建LinkedList节点），并能够利用代码内嵌（code-inlining）的优势。1.3
JVM的结果似乎显示出，在简单操作方面它的性能有着很大的不足，这一点很可能在以后的JVM版本中得到改进。
在这里我特别进行测试的是ArrayList相对于LinkedList的另一个优点，即预先确定集合大小的能力。具体地说，创建ArrayList的时候允许指定一个具体的大小（例如，在测试中ArrayList可以创建为拥有100个元素的容量），从而避免所有随着元素增多而增加集合规模的开销。表1括号中的数字显示了预先确定集合大小时性能的提高程度。LinkedList（直到
SDK 1.3）不能预先确定大小。
此外，ArrayList只生成少量的需要进行垃圾收集的对象，即，用来保存元素的内部数组对象，以及每次ArrayList容量不足需要进行扩展时创建的附加内部数组对象。LinkedList不管可能出现的任何删除操作，都为每一个插入操作生成一个节点对象。因此，LinkedList会给垃圾收集器带来相当多的工作。考虑到这些因素，对于任何中小规模的集合，我会选择使用ArrayList而不是LinkedList。
|
表2：构造一个大型集合（10,000个元素）
|
|
|
1.2 JVM
|
1.3 JVM
|
HotSpot 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 JVM
|
1.3 JVM
|
HotSpot 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强调的是，超大集合要求数据、集合类型、数据处理算法之间的恰到好处的配合 |