Map线程安全

在Java类库中出现的第一个关联的集合类是Hashtable，它是JDK 1.0的一部分。Hashtable提供了一种易于使用的、线程安全的、关联的map功能，这当然也是方便的。然而，线程安全性是凭代价换来的——Hashtable的所有方法都是同步的。 此时，无竞争的同步会导致可观的性能代价。

Hashtable的后继者HashMap是作为JDK1.2中的集合框架的一部分出现的，它通过提供一个不同步的基类和一个同步的包装器Collections.synchronizedMap，解决了线程安全性问题。 通过将基本的功能从线程安全性中分离开来，Collections.synchronizedMap允许需要同步的用户可以拥有同步，而不需要同步的用户则不必为同步付出代价。

Hashtable 和synchronizedMap所采取的获得同步的简单方法（同步Hashtable中或者同步的Map包装器对象中的每个方法）有两个主要的不足。

1，这种方法对于可伸缩性是一种障碍，因为一次只能有一个线程可以访问hash表。

2，这样仍不足以提供真正的线程安全性，许多公用的混合操作仍然需要额外的同步。虽然诸如get() 和put()之类的简单操作可以在不需要额外同步的情况下安全地完成，但还是有一些公用的操作序列 ，例如迭代或者put-if-absent（空则放入），需要外部的同步，以避免数据争用。

有条件的线程安全性 
同步的集合包装器synchronizedMap 和synchronizedList，有时也被称作有条件地线程安全——所有 单个的操作都是线程安全的，但是多个操作组成的操作序列却可能导致数据争用，因为在操作序列中控制流取决于前面操作的结果。 

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

1. Map m = Collections.synchronizedMap(new HashMap());
2.     List l = Collections.synchronizedList(new ArrayList());
3. 
   
4.     // put-if-absent idiom -- contains a race condition
5.     // may require external synchronization
6.     if (!map.containsKey(key))
7.       map.put(key, value);
8. 
   
9.     // ad-hoc iteration -- contains race conditions
10.     // may require external synchronization
11.     for (int i=0; i<list.size(); i++) {
12.       doSomething(list.get(i));
13.     }
14. 
    
15.     // normal iteration -- can throw ConcurrentModificationException
16.     // may require external synchronization
17.     for (Iterator i=list.iterator(); i.hasNext(); ) {
18.       doSomething(i.next());
19.     }

清单1中的问题：

1.第一片段展示了公用的put-if-absent语句块——如果一个条目不在Map中，那么添加这个条目。不幸的是， 在containsKey()方法返回到put() 方法被调用这段时间内，可能会有另一个线程也插入一个带有相同键的值。如果您想确保只有一次插入，您需要用一个对Map m进行同步的同步块将这一对语句包装起来。

2.List.size() 的结果在循环的执行期间可能会变得无效，因为另一个线程可以从这个列表中删除条目。如果时机不得当，在刚好进入循环的最后一次迭代之后有一个条目被另一个线程删除 了，则List.get()将返回null，而doSomething() 则很可能会抛出一个NullPointerException异常。

那么，采取什么措施才能避免这种情况呢？如果当您正在迭代一个List 时另一个线程也 可能正在访问这个List，那么在进行迭代时您必须使用一个synchronized 块将这个List包装起来。这样做虽然解决了数据争用问题，但是在并发性方面付出了更多的代价，因为在迭代期间锁住整个List会阻塞其他线程，使它们在很长一段时间内不能访问这个列表。

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

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

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

http://blog.csdn.net/yurenyang/article/details/2987888