Hashtable多線程遍歷問題

If a thread-safe implementation is not needed, it is recommended to use HashMap in place of code Hashtable. If a thread-safe highly-concurrent implementation is desired, then it is recommended to use ConcurrentHashMap in place of code Hashtable.

如上一段摘自Hashtable註釋。雖然Hashtable已經不被推薦使用了，但某種狀況下仍是會被使用。咱們知道Hashtable與HashMap一個很大的區別就是是否線程安全，Hashtable相對於HashMap來講是線程安全的。但Hashtable在使用過程當中，真的是線程安全麼？

最近在處理Wlan Framework中的一段邏輯，該部分邏輯使用了Hashtable存儲設備列表。該設備列表在本身的工做線程中分別有添加、刪除操做，並經過binder提供了查詢操做。查詢操做須要遍歷設備列表，因爲是經過binder跨進程調用的，所以獲取列表的線程與添加、刪除操做的線程並非同一個線程，從而遇到了ConcurrentModificationException。Hashtable雖然說是線程安全的，可是它僅僅是在添加、刪除等操做時是線程安全的，若是遍歷操做處理很差，一樣會拋出異常。

出問題的遍歷方式以下

1.  
   Iterator it;
2.  
   it = mDeviceMap.keySet().iterator();
3.  
   while(it.hasNext()) {
4.  
   String key = (String)it.next();
5.  
   ......
6.  
   }
7.  
    

查看Hashtable源碼，keySet返回的是Collections.SynchronizedSet對象。建立該對象時新建了一個KeySet對象，該KeySet爲Hashtable的非靜態內部類。此外還傳入了Hashtable.this賦值給了SynchronizedSet的mutex，做爲同步對象。

1.  
   public Set<K> keySet() {
2.  
   if (keySet == null)
3.  
   keySet = Collections.synchronizedSet(new KeySet(), this);
4.  
   return keySet;
5.  
   }
6.  
    

以下爲Collections.SynchronizedSet的實現，鑑於篇幅緣由省略了部分方法及實現內容。

1.  
   static class SynchronizedCollection<E> implements Collection<E>, Serializable {
2.  
   final Collection<E> c; // Backing Collection
3.  
   final Object mutex; // Object on which to synchronize
4.  
   SynchronizedCollection(Collection<E> c, Object mutex) {
5.  
   this.c = Objects.requireNonNull(c);
6.  
   this.mutex = Objects.requireNonNull(mutex);
7.  
   }
8.  
   public Object[] toArray() {
9.  
   synchronized (mutex) {return c.toArray();}
10.  
    }
11.  
    public <T> T[] toArray(T[] a) {
12.  
    synchronized (mutex) {return c.toArray(a);}
13.  
    }
14.  
     
15.  
    public Iterator<E> iterator() {
16.  
    return c.iterator(); // Must be manually synched by user!
17.  
    }
18.  
    }
19.  
     

如上mutex即爲Hashtable的實例，與Hashtable中的add、remove等操方法用的是同一把鎖。此外，經過註釋可知，使用iterator遍歷時，必需要本身進行同步操做。

Hashtable遍歷的方法

Hashtable遍歷的方法雖然有不少，但均是大同小異，這裏主要介紹兩種方案。
第一種方案，經過Hashtable的源碼可知，其put、remove等方法的同步是直接做用在方法上的，等價於使用Hashtable實例做爲同步鎖，所以以下遍歷方式是線程安全的。

1.  
   synchronized(mDeviceMap) {
2.  
   Iterator it;
3.  
   it = mDeviceMap.keySet().iterator();
4.  
   while(it.hasNext()) {
5.  
   String key = (String)it.next();
6.  
   ......
7.  
   }
8.  
   }
9.  
    

因爲使用迭代器遍歷拋出異常的根本緣由是expectedModCount != modCount，所以第二種方案即是不使用迭代器，而是從新建立一個數組，數組內容便是Hashtable中values保存的實例。這樣的好處是無需本身再作同步，代碼和邏輯看起來簡潔，固然也會帶來佔用額外空間以及效率方面的代價。

1.  
   int size = mDeviceMap.size();
2.  
   Device[] devices = mDeviceMap.values().toArray(new Device[size]);
3.  
   for (Device device: devices) {
4.  
   Log.d(TAG, "name = " + device.mName);
5.  
   ......
6.  
   }
7.  
    

兩種toArray轉換的區別

上面第二種遍歷方式，在monkey測試的時候竟然仍是拋出了異常，只不過此次是Device變量空指針異常。看到這個異常的時候一臉的懵逼。Hashtable的put方法在最開始的時候明明對value判空了，key和value都不容許爲空，那這個轉換來的value數組爲何會有空的成員？

雖然這個問題使用ConcurrentHashMap就能夠避免，但老是要弄個明白內心纔會踏實。那就一點點分析源碼吧。

既然是報Device爲空，那就說明轉換來的Device數組中有空成員。先分析mDeviceMap.values()，該方法同上面分析的keySet方法，返回的是SynchronizedCollection實例，這個應該沒問題，那就繼續分析後面的toArray方法了。

1.  
   public Object[] toArray() {
2.  
   synchronized (mutex) {return c.toArray();}
3.  
   }
4.  
   public <T> T[] toArray(T[] a) {
5.  
   synchronized (mutex) {return c.toArray(a);}
6.  
   }
7.  
    

經過上面能夠看出這裏的mutex即是Hashtable實例，c即是建立的Hashtable內部類ValueCollection的實例。SynchronizedCollection支持兩種toArray方法，且均進行了同步，也就是整個轉換過程當中都有作同步操做。到這有點更懵了，既然作了同步，爲啥還會有value爲空的問題，只能接着往下看。上面c.toArray(a)調用的是ValueCollection的方法，ValueCollection繼承自AbstractCollection，那就轉到AbstractCollection的toArray(T[] a)方法。

1.  
   public <T> T[] toArray(T[] a) {
2.  
   // Estimate size of array; be prepared to see more or fewer elements
3.  
   int size = size();
4.  
   //注意，這裏對傳入的數組length與size作了比較
5.  
   T[] r = a.length >= size ? a :
6.  
   (T[])java.lang.reflect.Array
7.  
   .newInstance(a.getClass().getComponentType(), size);
8.  
   Iterator<E> it = iterator();
9.  
   for (int i = 0; i < r.length; i++) {
10.  
    if (! it.hasNext()) { // fewer elements than expected
11.  
    if (a == r) {
12.  
    r[i] = null; // null-terminate
13.  
    } else if (a.length < i) {
14.  
    return Arrays.copyOf(r, i);
15.  
    } else {
16.  
    System.arraycopy(r, 0, a, 0, i);
17.  
    if (a.length > i) {
18.  
    a[i] = null;
19.  
    }
20.  
    }
21.  
    return a;
22.  
    }
23.  
    r[i] = (T)it.next();
24.  
    }
25.  
    // more elements than expected
26.  
    return it.hasNext() ? finishToArray(r, it) : r;
27.  
    }
28.  
     

注意到最終返回的是數組r，且在for循環中，確實有對r中內容賦值爲null的狀況，問題應該就出在這裏了。若是咱們調用toArray(T[] a)時，提供的數組a長度比實際長度大，多出的部分就會被null填充；若是數組a的長度比實際長度小，則會新建一個數組，並一一填充。

那麼最開始的空指針是怎麼出現的呢？

1.  
   int size = mDeviceMap.size();
2.  
   Device[] devices = mDeviceMap.values().toArray(new Device[size]);
3.  
    

上面兩條語句，雖然各自都進行了同步，可是這兩條語句總體並未進行同步，當獲取size以後，其餘線程此時恰好調用了remove操做，進而致使在調用toArray的時候，實際size比咱們提供的數組a的長度要小，從而致使返回的數組多出部分會被null填充。

1.  
   public Object[] toArray() {
2.  
   // Estimate size of array; be prepared to see more or fewer elements
3.  
   Object[] r = new Object[size()];
4.  
   Iterator<E> it = iterator();
5.  
   for (int i = 0; i < r.length; i++) {
6.  
   if (! it.hasNext()) // fewer elements than expected
7.  
   return Arrays.copyOf(r, i);
8.  
   r[i] = it.next();
9.  
   }
10.  
    return it.hasNext() ? finishToArray(r, it) : r;
11.  
    }
12.  
     

再來看不帶參數的toArray方法。該方法比較簡單，直接根據實際的size建立數組，並進行填充。因爲該方法調用時進行了同步，所以整個轉換過程都是同步的，從而直接使用toArray()轉換是線程安全的。

總結

1. Hashtable已經不推薦使用了，若是無需考慮線程安全，直接使用Hashmap；須要考慮線程安全時，使用ConcurrentHashMap。
2. Hashtable遍歷時，仍是須要注意線程安全問題。
3. SynchronizedCollection的兩種toArray方法是不一樣的，如無特殊要求，建議使用無參的方法。
4. 遇到問題要多看源碼實現。