工作中需要在某个业务类中设置一个将一些对象缓存在内存中的一个缓存机制（单机）。于是有了以下类似结构的实现：

业务类HashtableIteratorTest中，使用静态内部类Cache来存储缓存，缓存的直接载体为内部类中的静态成员cacheMap。

内部类Cache为线程类，线程的执行内容为每10秒钟进行一次缓存刷新。（刷新结果是清除掉缓存时间超过10秒的内容）

业务类HashtableIteratorTest在初始化时，启动内部类的线程，并实现一些存入缓存和读取缓存的方法。

代码中的main方法模拟每秒钟增加一个缓存。

于是，代码遇到了以下问题：

上述代码第53行，迭代缓存Map的时候抛出了java.util.ConcurrentModificationException异常。

首先，ConcurrentModificationException在JDK中的描述为：

当方法检测到对象的并发修改，但不允许这种修改时，抛出此异常。

很奇怪，我明明在refresh()中对cacheMap遍历时，已经对cacheMap对象加锁，可是在next的时候仍然抛出了这个异常。

于是查看JDK源码，发现：

KeySet是Set接口的一个子类，是Hashtable的内部类。返回的是将KeySet经过加锁后的包装类SynchronizedSet的对象。

SynchronizedSet类的部分源码如下：

代码中变量c为KeySet对象，mutex为调用keySet()方法的对象，即加锁的对象为cacheMap。（Collections同步Set的原理）

注意代码中iterator()方法中的注释：用户必须手动同步！

于是笔者仿佛找到了一些头绪。

KeySet的iterator()方法最终返回的是Enumerator的对象，Enumerator是Hashtable的内部类。以下截取重要代码：

可以看到，问题的发生源头找到了，当modCount != expectedModCount时，就会抛出异常。

那么，modCount和expectedModCount是做什么的？

modCount字段在其外部类Hashtable中，注释的大概意思是：这个数字记录了，对hashtable内部结构产生变化的操作次数。如rehash()、put(K key, V value)中，都会有modCount++。

expectedModCount字段在Enumerator类中，并在Enumerator（迭代器）初始化时，赋予modCount的值。其注释的主要内容为：用于检测并发修改。

其值在迭代器的remove()方法中，与modCount一同自增（见上述代码中remove()方法中第22、23行）。

于是真相浮于水面：在获得迭代器时，expectedModCount与modCount值相等，但迭代的同时，第55行的cacheMap.remove(key)使modCount值自增1，导致modCount != expectedModCount，于是抛出ConcurrentModificationException异常。

由上面的结论得出：

在Hashtable迭代的过程中，除迭代器中的操作外，凡对该map对象有产生结构变化的操作时，属于并发修改。迭代器将不能正常工作。

这就是此类Hashtable在遍历时，抛出ConcurrentModificationException异常的来由，用加锁同步两个操作不是问题所在。

本文问题解决方法很简单：将55行的使用map调用删除对象

改为在迭代器中删除对象

即可。

也以此推断出此类异常的解决方式：

要么不要在迭代的时候进行rehash()、put(K key, V value)、remove(Object key)等会对map结构产生变化的操作；要么就在迭代器中做可能的操作。