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在可伸缩性方面的比较

CopyOnWriteArrayList 在那些遍历操作大大地多于插入或移除操作的并发应用程序中，一般用 CopyOnWriteArrayList 类替代 ArrayList 。如果是用于存放一个侦听器（listener）列表，例如在AWT或Swing应用程序中，或者在常见的JavaBean中，那么这种情况很常见（相关的 CopyOnWriteArraySet 使用一个 CopyOnWriteArrayList 来实现 Set 接口）。 如果您正在使用一个普通的 ArrayList 来存放一个侦听器列表，那么只要该列表是可变的，而且可能要被多个线程访问，您就必须要么在对其进行迭代操作期间，要么在迭代前进行的克隆操作期间，锁定整个列表，这两种做法的开销都很大。当对列表执行会引起列表发生变化的操作时， CopyOnWriteArrayList 并不是为列表创建一个全新的副本，它的迭代器肯定能够返回在迭代器被创建时列表的状态，而不会抛出 ConcurrentModificationException 。在对列表进行迭代之前不必克隆列表或者在迭代期间锁定列表，因为迭代器所看到的列表的副本是不变的。换句话说， CopyOnWriteArrayList 含有对一个不可变数组的一个可变的引用，因此，只要保留好那个引用，您就可以获得不可变的线程安全性的好处，而且不用锁定列表。