Map和List性能测试

Map mm=new HashMap(100);
   List l=new ArrayList(100);
   long l1=System.currentTimeMillis();
   for(int i=0;i<1000000;i++){
    mm.put(i, i);
   }
   System.out.println("put map="+(System.currentTimeMillis()-l1));
   l1=System.currentTimeMillis();
   for(int i=0;i<1000000;i++){
    l.add(i);
   }
   System.out.println("add list="+(System.currentTimeMillis()-l1));
   l1=System.currentTimeMillis();
   for(int i=0;i<1000000;i++){
    mm.get(i);
   }
   System.out.println("get map="+(System.currentTimeMillis()-l1));
   l1=System.currentTimeMillis();
   for(int i=0;i<1000000;i++){
    l.get(i);
   }
   System.out.println("get list="+(System.currentTimeMillis()-l1));
   

put map=1031
add list=157
get map=93
get list=16

竟然性能相差这大！！

ps:这是基本单线程测试的

 

 付多线程版本的Map和List测试，介绍

ConcurrentHashMap

util.concurrent 包中的 ConcurrentHashMap 类（也将出如今JDK 1.5中的 java.util.concurrent 包中）是对 Map 的线程安全的实现，比起 synchronizedMap 来，它提供了好得多的并发性。多个读操做几乎总能够并发地执行，同时进行的读和写操做一般也能并发地执行，而同时进行的写操做仍然能够不时地并发进行（相关的类也提供了相似的多个读线程的并发性，可是，只容许有一个活动的写线程） 。ConcurrentHashMap 被设计用来优化检索操做；实际上，成功的 get() 操做完成以后一般根本不会有锁着的资源。要在不使用锁的状况下取得线程安全性须要必定的技巧性，而且须要对Java内存模型（Java Memory Model）的细节有深刻的理解。 ConcurrentHashMap 实现，加上 util.concurrent 包的其余部分，已经被研究正确性和线程安全性的并发专家所正视。在下个月的文章中，咱们将看看 ConcurrentHashMap 的实现的细节。

ConcurrentHashMap 经过稍微地松弛它对调用者的承诺而得到了更高的并发性。检索操做将能够返回由最近完成的插入操做所插入的值，也能够返回在步调上是并发的插入操做所添加的值（可是决不会返回一个没有意义的结果）。由 ConcurrentHashMap.iterator() 返回的 Iterators 将每次最多返回一个元素，而且决不会抛出 ConcurrentModificationException 异常，可是可能会也可能不会反映在该迭代器被构建以后发生的插入操做或者移除操做。在对集合进行迭代时，不须要表范围的锁就能提供线程安全性。在任何不依赖于锁整个表来防止更新的应用程序中，可使用 ConcurrentHashMap 来替代 synchronizedMap 或 Hashtable 。

上述改进使得 ConcurrentHashMap 可以提供比 Hashtable 高得多的可伸缩性，并且，对于不少类型的公用案例（好比共享的cache）来讲，还不用损失其效率。

好了多少？

表 1对 Hashtable 和 ConcurrentHashMap 的可伸缩性进行了粗略的比较。在每次运行过程当中， n 个线程并发地执行一个死循环，在这个死循环中这些线程从一个 Hashtable 或者 ConcurrentHashMap 中检索随机的key value，发如今执行 put() 操做时有80%的检索失败率，在执行操做时有1%的检索成功率。测试所在的平台是一个双处理器的Xeon系统，操做系统是Linux。数据显示了10,000,000次迭代以毫秒计的运行时间，这个数据是在将对 ConcurrentHashMap的 操做标准化为一个线程的状况下进行统计的。您能够看到，当线程增长到多个时， ConcurrentHashMap 的性能仍然保持上升趋势，而 Hashtable 的性能则随着争用锁的状况的出现而当即降了下来。

比起一般状况下的服务器应用，此次测试中线程的数量看上去有点少。然而，由于每一个线程都在不停地对表进行操做，因此这与实际环境下使用这个表的更多数量的线程的争用状况基本等同。

表 1.Hashtable 与 ConcurrentHashMap在可伸缩性方面的比较

线程数	ConcurrentHashMap	Hashtable
1	1.00	1.03
2	2.59	32.40
4	5.58	78.23
8	13.21	163.48
16	27.58	341.21
32	57.27	778.41

CopyOnWriteArrayList

在那些遍历操做大大地多于插入或移除操做的并发应用程序中，通常用 CopyOnWriteArrayList 类替代 ArrayList 。若是是用于存放一个侦听器（listener）列表，例如在AWT或Swing应用程序中，或者在常见的JavaBean中，那么这种状况很常见（相关的 CopyOnWriteArraySet 使用一个 CopyOnWriteArrayList 来实现 Set 接口）。

若是您正在使用一个普通的 ArrayList 来存放一个侦听器列表，那么只要该列表是可变的，并且可能要被多个线程访问，您就必需要么在对其进行迭代操做期间，要么在迭代前进行的克隆操做期间，锁定整个列表，这两种作法的开销都很大。当对列表执行会引发列表发生变化的操做时， CopyOnWriteArrayList 并非为列表建立一个全新的副本，它的迭代器确定可以返回在迭代器被建立时列表的状态，而不会抛出 ConcurrentModificationException 。在对列表进行迭代以前没必要克隆列表或者在迭代期间锁定列表，由于迭代器所看到的列表的副本是不变的。换句话说， CopyOnWriteArrayList 含有对一个不可变数组的一个可变的引用，所以，只要保留好那个引用，您就能够得到不可变的线程安全性的好处，并且不用锁定列表。