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虽说是线程安全的，但是它仅仅是在添加、删除等操作时是线程安全的，如果遍历操作处理不好，同样会抛出异常。

出问题的遍历方式如下

Iterator it;
it = mDeviceMap.keySet().iterator();
while(it.hasNext()) {
String key = (String)it.next();
......
}

查看Hashtable源码，keySet返回的是Collections.SynchronizedSet对象。创建该对象时新建了一个KeySet对象，该KeySet为Hashtable的非静态内部类。此外还传入了Hashtable.this赋值给了SynchronizedSet的mutex，作为同步对象。

public Set<K> keySet() {
if (keySet == null)
keySet = Collections.synchronizedSet(new KeySet(), this);
return keySet;
}

如下为Collections.SynchronizedSet的实现，鉴于篇幅原因省略了部分方法及实现内容。

static class SynchronizedCollection<E> implements Collection<E>, Serializable {
final Collection<E> c; // Backing Collection
final Object mutex; // Object on which to synchronize
SynchronizedCollection(Collection<E> c, Object mutex) {
this.c = Objects.requireNonNull(c);
this.mutex = Objects.requireNonNull(mutex);
}
public Object[] toArray() {
synchronized (mutex) {return c.toArray();}
}
public <T> T[] toArray(T[] a) {
synchronized (mutex) {return c.toArray(a);}
}
public Iterator<E> iterator() {
return c.iterator(); // Must be manually synched by user!
}
}

如上mutex即为Hashtable的实例，与Hashtable中的add、remove等操方法用的是同一把锁。此外，通过注释可知，使用iterator遍历时，必须要自己进行同步操作。

Hashtable遍历的方法

Hashtable遍历的方法虽然有很多，但均是大同小异，这里主要介绍两种方案。
第一种方案，通过Hashtable的源码可知，其put、remove等方法的同步是直接作用在方法上的，等价于使用Hashtable实例作为同步锁，因此如下遍历方式是线程安全的。

synchronized(mDeviceMap) {
Iterator it;
it = mDeviceMap.keySet().iterator();
while(it.hasNext()) {
String key = (String)it.next();
......
}
}

由于使用迭代器遍历抛出异常的根本原因是expectedModCount != modCount，因此第二种方案便是不使用迭代器，而是重新创建一个数组，数组内容即是Hashtable中values保存的实例。这样的好处是无需自己再做同步，代码和逻辑看起来简洁，当然也会带来占用额外空间以及效率方面的代价。

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

两种toArray转换的区别

上面第二种遍历方式，在monkey测试的时候居然还是抛出了异常，只不过这次是Device变量空指针异常。看到这个异常的时候一脸的懵逼。Hashtable的put方法在最开始的时候明明对value判空了，key和value都不允许为空，那这个转换来的value数组为什么会有空的成员？

虽然这个问题使用ConcurrentHashMap就可以避免，但总是要弄个明白心里才会踏实。那就一点点分析源码吧。

既然是报Device为空，那就说明转换来的Device数组中有空成员。先分析mDeviceMap.values()，该方法同上面分析的keySet方法，返回的是SynchronizedCollection实例，这个应该没问题，那就继续分析后面的toArray方法了。

public Object[] toArray() {
synchronized (mutex) {return c.toArray();}
}
public <T> T[] toArray(T[] a) {
synchronized (mutex) {return c.toArray(a);}
}

通过上面可以看出这里的mutex便是Hashtable实例，c便是创建的Hashtable内部类ValueCollection的实例。SynchronizedCollection支持两种toArray方法，且均进行了同步，也就是整个转换过程中都有做同步操作。到这有点更懵了，既然做了同步，为啥还会有value为空的问题，只能接着往下看。上面c.toArray(a)调用的是ValueCollection的方法，ValueCollection继承自AbstractCollection，那就转到AbstractCollection的toArray(T[] a)方法。

public <T> T[] toArray(T[] a) {
// Estimate size of array; be prepared to see more or fewer elements
int size = size();
//注意，这里对传入的数组length与size做了比较
T[] r = a.length >= size ? a :
(T[])java.lang.reflect.Array
.newInstance(a.getClass().getComponentType(), size);
Iterator<E> it = iterator();
for (int i = 0; i < r.length; i++) {
if (! it.hasNext()) { // fewer elements than expected
if (a == r) {
r[i] = null; // null-terminate
} else if (a.length < i) {
return Arrays.copyOf(r, i);
} else {
System.arraycopy(r, 0, a, 0, i);
if (a.length > i) {
a[i] = null;
}
}
return a;
}
r[i] = (T)it.next();
}
// more elements than expected
return it.hasNext() ? finishToArray(r, it) : r;
}

注意到最终返回的是数组r，且在for循环中，确实有对r中内容赋值为null的情况，问题应该就出在这里了。如果我们调用toArray(T[] a)时，提供的数组a长度比实际长度大，多出的部分就会被null填充；如果数组a的长度比实际长度小，则会新建一个数组，并一一填充。

那么最开始的空指针是怎么出现的呢？

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

上面两条语句，虽然各自都进行了同步，但是这两条语句整体并未进行同步，当获取size之后，其他线程此时刚好调用了remove操作，进而导致在调用toArray的时候，实际size比我们提供的数组a的长度要小，从而导致返回的数组多出部分会被null填充。

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

再来看不带参数的toArray方法。该方法比较简单，直接根据实际的size创建数组，并进行填充。由于该方法调用时进行了同步，因此整个转换过程都是同步的，从而直接使用toArray()转换是线程安全的。

总结

Hashtable已经不推荐使用了，如果无需考虑线程安全，直接使用Hashmap；需要考虑线程安全时，使用ConcurrentHashMap。
Hashtable遍历时，还是需要注意线程安全问题。
SynchronizedCollection的两种toArray方法是不同的，如无特殊要求，建议使用无参的方法。
遇到问题要多看源码实现。