從這一節(jié)開始正式進(jìn)入并發(fā)容器的部分，來看看JDK 6帶來了哪些并發(fā)容器。
在JDK 1.4以下只有Vector和Hashtable是線程安全的集合（也稱并發(fā)容器，Collections.synchronized*系列也可以看作是線程安全的實(shí)現(xiàn)）。從JDK 5開始增加了線程安全的Map接口ConcurrentMap和線程安全的隊(duì)列BlockingQueue（盡管Queue也是同時(shí)期引入的新的集合，但是規(guī)范并沒有規(guī)定一定是線程安全的，事實(shí)上一些實(shí)現(xiàn)也不是線程安全的，比如PriorityQueue、ArrayDeque、LinkedList等，在Queue章節(jié)中會(huì)具體討論這些隊(duì)列的結(jié)構(gòu)圖和實(shí)現(xiàn)）。
在介紹ConcurrencyMap之前先來回顧下Map的體系結(jié)構(gòu)。下圖描述了Map的體系結(jié)構(gòu)，其中藍(lán)色字體的是JDK 5以后新增的并發(fā)容器。
針對(duì)上圖有以下幾點(diǎn)說明：
- Hashtable是JDK 5之前Map唯一線程安全的內(nèi)置實(shí)現(xiàn)（Collections.synchronizedMap不算）。特別說明的是Hashtable的t是小寫的（不知道為啥），Hashtable繼承的是Dictionary（Hashtable是其唯一公開的子類），并不繼承AbstractMap或者HashMap。盡管Hashtable和HashMap的結(jié)構(gòu)非常類似，但是他們之間并沒有多大聯(lián)系。
- ConcurrentHashMap是HashMap的線程安全版本，ConcurrentSkipListMap是TreeMap的線程安全版本。
- 最終可用的線程安全版本Map實(shí)現(xiàn)是ConcurrentHashMap/ConcurrentSkipListMap/Hashtable/Properties四個(gè)，但是Hashtable是過時(shí)的類庫(kù)，因此如果可以的應(yīng)該盡可能的使用ConcurrentHashMap和ConcurrentSkipListMap。
回到正題來，這個(gè)小節(jié)主要介紹ConcurrentHashMap的API以及應(yīng)用，下一節(jié)才開始將原理和分析。
除了實(shí)現(xiàn)Map接口里面對(duì)象的方法外，ConcurrentHashMap還實(shí)現(xiàn)了ConcurrentMap里面的四個(gè)方法。
V putIfAbsent(K key,V value)
如果不存在key對(duì)應(yīng)的值，則將value以key加入Map，否則返回key對(duì)應(yīng)的舊值。這個(gè)等價(jià)于清單1 的操作：
清單1 putIfAbsent的等價(jià)操作
if (!map.containsKey(key))
return map.put(key, value);
else
return map.get(key);
在前面的章節(jié)中提到過，連續(xù)兩個(gè)或多個(gè)原子操作的序列并不一定是原子操作。比如上面的操作即使在Hashtable中也不是原子操作。而putIfAbsent就是一個(gè)線程安全版本的操作的。
有些人喜歡用這種功能來實(shí)現(xiàn)單例模式，例如清單2。
清單2 一種單例模式的實(shí)現(xiàn)
package xylz.study.concurrency;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ConcurrentMap;
public class ConcurrentDemo1 {
private static final ConcurrentMap<String, ConcurrentDemo1> map = new ConcurrentHashMap<String, ConcurrentDemo1>();
private static ConcurrentDemo1 instance;
public static ConcurrentDemo1 getInstance() {
if (instance == null) {
map.putIfAbsent("INSTANCE", new ConcurrentDemo1());
instance = map.get("INSTANCE");
}
return instance;
}
private ConcurrentDemo1() {
}
}
當(dāng)然這里只是一個(gè)操作的例子，實(shí)際上在單例模式文章中有很多的實(shí)現(xiàn)和比較。清單2 在存在大量單例的情況下可能有用，實(shí)際情況下很少用于單例模式。但是這個(gè)方法避免了向Map中的同一個(gè)Key提交多個(gè)結(jié)果的可能，有時(shí)候在去掉重復(fù)記錄上很有用（如果記錄的格式比較固定的話）。
boolean remove(Object key,Object value)
只有目前將鍵的條目映射到給定值時(shí)，才移除該鍵的條目。這等價(jià)于清單3 的操作。
清單3 remove(Object,Object)的等價(jià)操作
if (map.containsKey(key) && map.get(key).equals(value)) {
map.remove(key);
return true;
}
return false;
由于集合類通常比較的hashCode和equals方法，而這兩個(gè)方法是在Object對(duì)象里面，因此兩個(gè)對(duì)象如果hashCode一致，并且覆蓋了equals方法后也一致，那么這兩個(gè)對(duì)象在集合類里面就是“相同”的，不管是否是同一個(gè)對(duì)象或者同一類型的對(duì)象。也就是說只要key1.hashCode()==key2.hashCode() && key1.equals(key2)，那么key1和key2在集合類里面就認(rèn)為是一致，哪怕他們的Class類型不一致也沒關(guān)系，所以在很多集合類里面允許通過Object來類型來比較（或者定位）。比如說Map盡管添加的時(shí)候只能通過制定的類型<K,V>，但是刪除的時(shí)候卻允許通過一個(gè)Object來操作，而不必是K類型。
既然Map里面有一個(gè)remove(Object)方法，為什么ConcurrentMap還需要remove(Object,Object)方法呢？這是因?yàn)楸M管Map里面的key沒有變化，但是value可能已經(jīng)被其他線程修改了，如果修改后的值是我們期望的，那么我們就不能拿一個(gè)key來刪除此值，盡管我們的期望值是刪除此key對(duì)于的舊值。
這種特性在原子操作章節(jié)的AtomicMarkableReference和AtomicStampedReference里面介紹過。
boolean replace(K key,V oldValue,V newValue)
只有目前將鍵的條目映射到給定值時(shí)，才替換該鍵的條目。這等價(jià)于清單4 的操作。
清單4 replace(K,V,V)的等價(jià)操作
if (map.containsKey(key) && map.get(key).equals(oldValue)) {
map.put(key, newValue);
return true;
}
return false;
V replace(K key,V value)
只有當(dāng)前鍵存在的時(shí)候更新此鍵對(duì)于的值。這等價(jià)于清單5 的操作。
清單5 replace(K,V)的等價(jià)操作
if (map.containsKey(key)) {
return map.put(key, value);
}
return null;
replace(K,V,V)相比replace(K,V)而言，就是增加了匹配oldValue的操作。
其實(shí)這4個(gè)擴(kuò)展方法，是ConcurrentMap附送的四個(gè)操作，其實(shí)我們更關(guān)心的是Map本身的操作。當(dāng)然如果沒有這4個(gè)方法，要完成類似的功能我們可能需要額外的鎖，所以有總比沒有要好。比如清單6，如果沒有putIfAbsent內(nèi)置的方法，我們?nèi)绻瓿纱瞬僮骶托枰耆i住整個(gè)Map，這樣就大大降低了ConcurrentMap的并發(fā)性。這在下一節(jié)中有詳細(xì)的分析和討論。
清單6 putIfAbsent的外部實(shí)現(xiàn)
public V putIfAbsent(K key, V value) {
synchronized (map) {
if (!map.containsKey(key)) return map.put(key, value);
return map.get(key);
}
}
參考資料：
©2009-2014 IMXYLZ
|求賢若渴