Hashtable、synchronizedMap、ConcurrentHashMap 比较

        Doug Lea的util.concurrent包除了包含许多其余有用的并发构造块以外，还包含了一些主要集合类型List和Map的高性能的、线程安全的实现。Brian Goetz向您展现了用ConcurrentHashMap替换Hashtable或synchronizedMap，将有多少并发程序获益。 
        在Java类库中出现的第一个关联的集合类是Hashtable，它是JDK 1.0的一部分。Hashtable提供了一种易于使用的、线程安全的、关联的map功能，这固然也是方便的。然而，线程安全性是凭代价换来的——Hashtable的全部方法都是同步的。 此时，无竞争的同步会致使可观的性能代价。Hashtable的后继者HashMap是做为JDK1.2中的集合框架的一部分出现的，它经过提供一个不一样步的基类和一个同步的包装器Collections.synchronizedMap，解决了线程安全性问题。 经过将基本的功能从线程安全性中分离开来，Collections.synchronizedMap容许须要同步的用户能够拥有同步，而不须要同步的用户则没必要为同步付出代价。 

Hashtable 和 synchronizedMap所采起的得到同步的简单方法（同步Hashtable中或者同步的Map包装器对象中的每一个方法）有两个主要的不足。首先，这种方法对于可伸缩性是一种障碍，由于一次只能有一个线程能够访问hash表。 同时，这样仍不足以提供真正的线程安全性，许多公用的混合操做仍然须要额外的同步。虽然诸如get() 和 put()之类的简单操做能够在不须要额外同步的状况下安全地完成，但仍是有一些公用的操做序列 ，例如迭代或者put-if-absent（空则放入），须要外部的同步，以免数据争用。 

有条件的线程安全性 

同步的集合包装器 synchronizedMap 和 synchronizedList，有时也被称做有条件地线程安全——全部 单个的操做都是线程安全的，可是多个操做组成的操做序列却可能致使数据争用，由于在操做序列中控制流取决于前面操做的结果。 清单1中第一片断展现了公用的put-if-absent语句块——若是一个条目不在Map中，那么添加这个条目。不幸的是， 在containsKey()方法返回到put() 方法被调用这段时间内，可能会有另外一个线程也插入一个带有相同键的值。若是您想确保只有一次插入，您须要用一个对Map m进行同步的同步块将这一对语句包装起来。 

清单1中其余的例子与迭代有关。在第一个例子中，List.size() 的结果在循环的执行期间可能会变得无效，由于另外一个线程能够从这个列表中删除条目。若是时机不得当，在恰好进入循环的最后一次迭代以后有一个条目被另外一个线程删除 了，则List.get()将返回null，而doSomething() 则极可能会抛出一个NullPointerException异常。那么，采起什么措施才能避免这种状况呢？若是当您正在迭代一个List 时另外一个线程也 可能正在访问这个 List，那么在进行迭代时您必须使用一个synchronized 块将这个List 包装起来， 在List 1 上同步，从而锁住整个List。这样作虽然解决了数据争用问题，可是在并发性方面付出了更多的代价，由于在迭代期间锁住整个List会阻塞其余线程，使它们在很长一段时间内不能访问这个列表。 

集合框架引入了迭代器，用于遍历一个列表或者其余集合，从而优化了对一个集合中的元素进行迭代的过程。然而，在java.util 集合类中实现的迭代器极易崩溃，也就是说，若是在一个线程正在经过一个Iterator遍历集合时，另外一个线程也来修改这个 集合，那么接下来的Iterator.hasNext() 或 Iterator.next()调用将抛出ConcurrentModificationException异常。就拿 刚才这个例子来说，若是想要防止出现ConcurrentModificationException异常，那么当您正在进行迭代时，您必须 使用一个在 List l上同步的synchronized块将该 List 包装起来，从而锁住整个 List。（或者，您也能够调用List.toArray()，在 不一样步的状况下对数组进行迭代，可是若是列表比较大的话这样作代价很高）。 

清单 1. 同步的map中的公用竞争条件 

            Map m = Collections.synchronizedMap(new HashMap()); 
            List l = Collections.synchronizedList(new ArrayList()); 
            // put-if-absent idiom -- contains a race condition 
            // may require external synchronization 
            if (!map.containsKey(key)) 
            map.put(key, value); 
            // ad-hoc iteration -- contains race conditions 
            // may require external synchronization 
            for (int i=0; i<list.size(); i++) { 
            doSomething(list.get(i)); 
            } 
            // normal iteration -- can throw ConcurrentModificationException 
            // may require external synchronization 
            for (Iterator i=list.iterator(); i.hasNext(); ) { 
            doSomething(i.next()); 
            } 

信任的错觉 

synchronizedList 和 synchronizedMap提供的有条件的线程安全性也带来了一个隐患——开发者会假设，由于这些集合都是同步的，因此它们都是线程安全的，这样一来他们对于正确地同步混合操做这件事就会疏忽。其结果是尽管表面上这些程序在负载较轻的时候可以正常工做，可是一旦负载较重，它们就会开始抛出NullPointerException 或 ConcurrentModificationException。 

可伸缩性问题 

可伸缩性指的是一个应用程序在工做负载和可用处理资源增长时其吞吐量的表现状况。一个可伸缩的程序可以经过使用更多的处理器、内存或者I/O带宽来相应地处理更大的工做负载。锁住某个共享的资源以得到独占式的访问这种作法会造成可伸缩性瓶颈——它使其余线程不能访问那个资源，即便有空闲的处理器能够调用那些线程也无济于事。为了取得可伸缩性，咱们必须消除或者减小咱们对独占式资源锁的依赖。 

同步的集合包装器以及早期的Hashtable 和 Vector类带来的更大的问题是，它们在单个的锁 上进行同步。这意味着一次只有一个线程能够访问集合，若是有一个线程正在读一个Map，那么全部其余想要读或者写这个Map的线程就必须等待。最多见的Map操做，get() 和 put()，可能比表面上要进行更多的处理——当遍历一个hash表的bucket以期找到某一特定的key时，get()必须对大量的候选bucket调用Object.equals()。若是key类所使用的hashCode()函数不能将value均匀地分布在整个hash表范围内，或者存在大量的hash冲突，那么某些bucket链就会比其余的链长不少，而遍历一个长的hash链以及对该hash链上必定百分比的元素调用 equals()是一件很慢的事情。在上述条件下，调用 get() 和 put() 的代价高的问题不只仅是指访问过程的缓慢，并且，当有线程正在遍历那个hash链时，全部其余线程都被锁在外面，不能访问这个Map。 

（哈希表根据一个叫作hash的数字关键字（key）将对象存储在bucket中。hash value是从对象中的值计算得来的一个数字。每一个不一样的hash value都会建立一个新的bucket。要查找一个对象，您只须要计算这个对象的hash value并搜索相应的bucket就好了。经过快速地找到相应的bucket，就能够减小您须要搜索的对象数量了。译者注） 

get()执行起来可能会占用大量的时间，而在某些状况下，前面已经做了讨论的有条件的线程安全性问题会让这个问题变得还要糟糕得多。清单1 中演示的争用条件经常使得对单个集合的锁在单个操做执行完毕以后还必须继续保持一段较长的时间。若是您要在整个迭代期间都保持对集合的锁，那么其余的线程就会在锁外停留很长的一段时间，等待解锁。

 

实例：一个简单的cache 

Map在服务器应用中最多见的应用之一就是实现一个cache。服务器应用可能须要缓存文件内容、生成的页面、数据库查询的结果、与通过解析的XML文件相关的DOM树，以及许多其余类型的数据。cache的主要用途是重用前一次处理得出的结果 以减小服务时间和增长吞吐量。cache工做负载的一个典型的特征就是检索大大多于更新，所以（理想状况下）cache可以提供很是好的get()性能。不过，使用会 妨碍性能的cache还不如彻底不用cache。 

若是使用 synchronizedMap 来实现一个cache，那么您就在您的应用程序中引入了一个潜在的可伸缩性瓶颈。由于一次只有一个线程能够访问Map，这 些线程包括那些要从Map中取出一个值的线程以及那些要将一个新的(key, value)对插入到该map中的线程。 

减少锁粒度 

提升HashMap的并发性同时还提供线程安全性的一种方法是废除对整个表使用一个锁的方式，而采用对hash表的每一个bucket都使用一个锁的方式（或者，更常见的是，使用一个锁池，每一个锁负责保护几个bucket） 。这意味着多个线程能够同时地访问一个Map的不一样部分，而没必要争用单个的集合范围的锁。这种方法可以直接提升插入、检索以及移除操做的可伸缩性。不幸的是，这种并发性是以必定的代价换来的——这使得对整个 集合进行操做的一些方法（例如 size() 或 isEmpty()）的实现更加困难，由于这些方法要求一次得到许多的锁，而且还存在返回不正确的结果的风险。然而，对于某些状况，例如实现cache，这样作是一个很好的折衷——由于检索和插入操做比较频繁，而 size() 和 isEmpty()操做则少得多。 

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含有对一个不可变数组的一个可变的引用，所以，只要保留好那个引用，您就能够得到不可变的线程安全性的好处，并且不用锁 定列表。 

结束语 

        同步的集合类Hashtable 和 Vector，以及同步的包装器类 Collections.synchronizedMap 和 Collections.synchronizedList，为Map 和 List提供了基本的有条件的线程安全的实现。然而，某些因素使得它们并不适用于具备高度并发性的应用程序中——它们的 集合范围的单锁特性对于可伸缩性来讲是一个障碍，并且，不少时候还必须在一段较长的时间内锁定一个集合，以防止出现ConcurrentModificationExceptions异常。 ConcurrentHashMap 和 CopyOnWriteArrayList实现提供了更高的并发性，同时还保住了线程安全性，只不过在对其调用者的承诺上打了点折扣。ConcurrentHashMap 和 CopyOnWriteArrayList并非在您使用HashMap 或 ArrayList的任何地方都必定有用，可是它们是设计用来优化某些特定的公用解决方案的。许多并发应用程序将从对它们的使用中得到好处。