今天在做项目时，遇到个bug，需求是app在特定的时候把广告缓存下来，合适的位置在展示，于是想的用hashmap列表存起来，key为位置的广告类型，value为广告对象。为了保证每个位置同时缓存的对象只有一个，于是在存储（add方法）前会将列表遍历一遍，如果有就remove掉。但是请求广告有时候并不在一个线程，于是今天在运行时，App闪退了。
报错：java.util.ConcurrentModificationException
可翻译成“并发修改异常”。
原因：触发fast-fail机制
fail-fast机制就是为了防止多线程修改集合造成并发问题的机制。
“快速失败”也就是fail-fast，它是Java集合的一种错误检测机制。当多个线程对集合进行结构上的改变的操作时，有可能会产生fail-fast机制。
报错代码：
list?.forEach { if (it["type"].toString() ==type) list?.remove(it) }
koltin的foreach其实就是java的增强for循环（类似于for(Object a:list){}）。这行代码实现的目标是想要在循环遍历的过程中找到指定数据并删除集合中的元素。
去官方文档查询，我这个应该是线程不安全导致的，想来也是，静态变量全局调用，本就不是线程安全的。所以当我们迭代一个ArrayList或者HashMap时,如果尝试对集合做一些修改操作（例如删除元素），可能会抛出java.util.ConcurrentModificationException的异常。
我原来用的数据结构是MutableList，继承于Collection，实现了Iterable接口。
foreach（java的for循环）的背后实现原理其实就是Iterator，迭代列表的Iterator中有一个变量expectedModCount，该变量会初始化和modCount相等，但如果接下来如果集合进行修改modCount改变，就会造成expectedModCount!=modCount，此时就会抛出java.util.ConcurrentModificationException异常。就是你的modCount改变了，但是还在迭代，导致expectedModCount和modCount不一样，导致报错。
之所以有modCount（修改次数）和expectedModCount（预期修改次数）这两个变量，就是为了辨别多线程修改集合时出现的错误。（细节可去查更多看源码）
源码
public class ArrayList<E> extends AbstractList<E> implements List<E>, RandomAccess, Cloneable, java.io.Serializable { ... ... /** * An optimized version of AbstractList.Itr */ private class Itr implements Iterator<E> { int cursor; // index of next element to return int lastRet = -1; // index of last element returned; -1 if no such int expectedModCount = modCount; // prevent creating a synthetic constructor Itr() {} public boolean hasNext() { return cursor != size; } @SuppressWarnings("unchecked") public E next() { checkForComodification();//checkForComodification方法检测modcount和expectedModCount是否相同 int i = cursor; if (i >= size) throw new NoSuchElementException(); Object[] elementData = ArrayList.this.elementData; if (i >= elementData.length) throw new ConcurrentModificationException(); cursor = i + 1; return (E) elementData[lastRet = i]; } public void remove() { if (lastRet < 0) throw new IllegalStateException(); checkForComodification(); try { ArrayList.this.remove(lastRet); cursor = lastRet; lastRet = -1; expectedModCount = modCount; } catch (IndexOutOfBoundsException ex) { throw new ConcurrentModificationException(); } } @Override public void forEachRemaining(Consumer<? super E> action) { Objects.requireNonNull(action); final int size = ArrayList.this.size; int i = cursor; if (i < size) { final Object[] es = elementData; if (i >= es.length) throw new ConcurrentModificationException(); for (; i < size && modCount == expectedModCount; i++) action.accept(elementAt(es, i)); // update once at end to reduce heap write traffic cursor = i; lastRet = i - 1; checkForComodification(); } } //检查计数是否相同 final void checkForComodification() { if (modCount != expectedModCount) throw new ConcurrentModificationException(); } } ... ...
由于我的广告很多时候都在加载（add操作），展示（remove操作），所以容易导致modCount和expectedModCount不相同，于是，便可以从线程安全下手。
方法一：加锁，Android里常会用到synchronized,在迭代前先枷锁，解决了多线程问题，但还是不能进行迭代add、clear等操作。不过我不迭代操作，也可以用。但是操作的地方太多了，不方便。
list?.let { synchronized(it) { list?.forEach {it1-> if (it1["type"].toString() == type) list?.remove(it1) } } }
方法二：CopyOnWriteArrayList，解决了多线程问题，可以执行各种等操作。
直接在定义的时候定义成CopyOnWriteArrayList就行了。
var cacheDataList: CopyOnWriteArrayList<HashMap<String, Any>>? = CopyOnWriteArrayList()
原理：CopyOnWriteArrayList是一个线程安全的ArrayList，CopyOnWrite容器即写时复制的容器，这是一种延时懒惰策略。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。CopyOnWrite并发容器用于读多写少的并发场景（可能以后还得优化一下，因为广告读写都挺多的,内存不大友好，或者可以试试ConcurrentHashMap）。
缺点：
1.内存问题.因为CopyOnWrite的写时复制机制，所以在进行写操作的时候，内存里会同时驻扎两个对象的内存
2.数据一致性问题。CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器。
方法三：不用默认的迭代器方法，而是获取到迭代器再去操作列表，这个是看的另一个方法，我没用。（此方法在单线程估计没问题，多线程不确定）
System.out.println("====迭代器遍历"); Iterator iterator = list.iterator(); while (iterator.hasNext()) { Object next = iterator.next(); //进行删除等操作
