Kotlin刨根问底(二)：for循环引发的一块儿“血案”

本文灵感来源于：群友遍历列表时remove元素引起异常，后对for循环的实现原理进行一系列的探究~

---

0x0、要点提炼

---

• 「普通for循环」相似代码，Java不报错，Kotlin却数组越界，因「循环条件不同」

Java：先判断是否知足条件 → 执行循环体 → 自增
Kotlin：遍历的是范围，直接进循环体

• 「加强for循环」= while循环 + 迭代器Iterator
• 「迭代器的设计哲学」→ 将 遍历行为 与 被遍历对象 分离，无需关心容器底层结构；
• 「ConcurrentModificationException」异常缘由(经过两个字段配合)

modCount → 记录列表结构修改次数，调用列表的remove方法，此值+1
 
expectedModCount → 预计修改次数，调用Itr迭代器中的remove方法时，会调用列表的remove方法，然后将modCount赋值给expectedModCount，即保证遍历过程当中两个值是相等的；
 
若是此时调用列表的remove方法，modCount增长1，而迭代器中的expectedModCount没变，二者不等，就会引起ConcurrentModificationException异常。

• 「fail-fast(快速失败)」

作系统设计的时候先考虑异常状况，一旦发生异常，直接中止并上报，一种用于提早预警的Bug检测机制；在集合中的应用就是：在遍历一个集合时，当集合结构被修改，直接抛出异常。

• 「规避ConcurrentModificationException的几种方法」

• 单线程：使用迭代器进行remove；
• 多线程：在使用迭代器处加锁(如synchronize)；
• 使用fail-safe(安全失败)机制的同步容器，如CopyOnWriteArrayList，在java.util.concurrent包中；

• 「Kotlin中使用toList()后能够规避异常的缘由」

建立了新的ArrayList用做遍历，remove移除的是旧ArrayList的元素，故互不影响

---

0x一、原由

---

寒冷的午后，在一个交流群里，一位开发者盆友抛出了下面的问题：

同时附带两张截图：

恰好在写代码的我，随手点开了 toList() 的源码：

惯性思惟 回了句：涉及到可变列表和不可变列表吧

接着截了个 Collection.kt 的文件结构图后，追加：

其实我并无理解他的问题，就开始跟起了RecyclerView的源码，再经历过一番排查得出：

应该和 Iterable，普通for循环，加强for循环有关

而后被拉去开了个两个半小时的用例评审…回来看到问题还没解决，看了聊天记录，捋了一下才弄懂他的问题：

一、普通for循环(下标遍历)，相似的代码，Java不报错，Kotlin却抛 IndexOutOfBoundsException；
二、加强for循环(foreach)，remove移除，都会抛 ConcurrentModificationException

看不懂？写个简单的代码演示下问题：

① Java

② Kotlin

初始化列表：

行吧，接着一个个讲解~

---

0x二、数组越界问题解析

---

缘由其实很简单「循环条件不同」，Java中是：

先判断是否知足条件 → 执行循环体 → 自增 ，打断点跟下i、ls.size()，记录以下：

0→五、1→四、2→三、3(此时size=3，判断条件不成立，不会自增，走循环体)，因此上面看到只打印了3次。

而Kotlin则不同，点开 for(i in l.indices) 里的indices：

噢，indices是一个扩展属性，值为：0..size - 1，一个范围(Range)，好比如今有5个元素，这个值就是：0..(5-1) → 0..4，你能够简单地把Range当作一个List(列表)，那么这里的 循环条件 就变成了：遍历这个范围，因此

0→五、1→四、2→三、3→3(这里是 直接进循环体，数组长度为3，访问3个，因此就引起了异常！)

到此：普通for循环的“血案(数组越界)”就此水落石出，接着看下加强for循环~

---

0x三、加强for循环异常分析

---

有读者可能有疑问，上述的Kotlin代码用的是 forEach 扩展方法，加强for循环不是应该这样写吗？

其实，forEach也是用的加强for循环，点开源码就知道了：

在加强for循环的基础上，传入一个处理函数，不了解函数式编程的可移步至：《八、Kotlin高阶函数与lambda表达式》

---

① 加强for循环的原理

---

反编译下加强for循环字节码，以下：

逐行源码解析：

• Iterator var → 定义迭代器类型的临时变量var1
• l.iterator() → 获取列表l的迭代器
• var1.hasNext() → 判断迭代器中是否有未遍历的元素
• Integer i = (Integer)var1.next() → 获取第一个未遍历元素，赋值给临时变量i
• l.remove(i) → 移除列表中的i元素

不难看出底层是：while循环 + Iterator(迭代器) 。

---

② 迭代器的设计“哲学”

---

设计模式中有一种模式「迭代器模式」

• 针对 =>「容器对象中元素的迭代访问」；
• 核心思想 => 将「遍历行为」与「被遍历对象」分离；
• 好处 => 无需关心容器的底层结构，拿到对象，使用迭代器便可遍历对象内部；

打开 Collection.kt，文件结构以下：

这里要对「Iterable」和「Iterator」进行区分：

• Iterable接口：实现此接口的集合对象支持迭代(可配合foreach使用)，定义了一个iterator()函数，返回一个Iterator迭代器对象。

• Iterator：迭代器，提供迭代机制的对象，代码以下：

两个函数：next() => 返回当前迭代元素；hasNext() => next前调用此方法判断是否迭代到终点
能够跟下实现看看：ListIterator → AbstractList：

跟IteratorImpl：

以上就是 迭代器的设计“哲学” 的简单讲解。

---

③ 寻根问底

---

回到加强for循环中remove元素引发的「ConcurrentModificationException」，此异常直接翻译：并发修改异常。
可是问题是：咱们并无用多线程修改集合，却引发这样的异常？跟一波异常，定位到：
java.util.ArrayList$Itr.checkForComodification

直译下变量名：modCount(修改次数)，expectedModCount(预计修改次数)，em…这是判断两值不等就直接抛异常？往上看：

modCount赋值给expectedModCount，说明二者一开始是相等的，那modCount是在哪里赋初值的呢？
点进去来到ArrayList的父类AbstractList

Tips：transient关键字 用来标记的成员变量不参与序列化过程)

在AbstractList中搜了下modCount，没发现有值变化的操做；
回到ArrayList，观察源码能够发现「在涉及结构变化的方法中，modCount都会自增1」

而add()，addAll() 方法虽然没有明写modCount++，但暗地里调用ensureCapacityInternal()完成自增：

到此，咱们知道了modCount →「会在ArrayList的结构发生变化时变化」
接着，到expectedModCount，定位到内部类 Itr：

类的组成比较简单：实现了Iterator迭代器接口，重写next()和hasNext()方法；定义了两个变量：cursor(下一个元素的下标)，lastRet(上一个元素的下标)；读者有疑问的多是next()里的：ArrayList.this.elementData，跟一下：

噢，就是一个缓存数组，长度为列表的容量，当第一个元素添加进来，会扩展至DEFAULT_CAPACITY：

看回remove()方法，调用ArrayList.this.remove()移除元素后，把modCount的赋值给expectedModCount；
继续往下走，由于此时二者相等，hasNext()执行checkForComodification()没抛出异常，按流程走是没问题的。

但：咱们上面跳过了迭代器，直接对列表进行了remove，而此时modCount已经+1，但expectedModCount没变，因此执行到checkForComodification就抛出异常了！

嗯，你有个大胆的想法？直接用迭代器进行remove会抛异常吗？那就试试：

行吧，用迭代器的方式remove，但此时已经不是加强for循环了，哈哈！

---

0x四、fail-fast(快速失败)

---

从上面咱们知道了异常发生的缘由了，那为什么要这样设计呢？这种玩法有个专业名词 →「fail-fast(快速失败)机制」

在作系统设计的时候先考虑异常状况，一旦发生异常，直接中止并上报。

举个简单的例子，写个两数相除的方法，若是不当心除以0，运行时就会引起异常ArithmeticException by/zero，而及时失败，则是在执行运算前，检测被除数是否为0，是直接抛出异常。示例以下：

行吧，一种检测Bug机制，用于提早预警，那ArrayList里为什么要用到这种机制呢？

→ 由于ArrayList不是线程安全的，多个线程同时访问同一个ArrayList可能会引发异常；
→ 引入及时失败是想着：若某个线程经过Iterator遍历时，集合内容被其余线程改变，抛出异常；

在上面的例子中，咱们利用迭代器遍历remove的方式来规避ConcurrentModificationException，
但那是只有在单个线程访问列表，若是是有多个线程在访问呢？写个例子试试：

行吧，抛异常了，那有在多线程的时候有什么办法规避呢？换个线程安全的容器，好比：Vector？

同样会抛异常，Vector虽然采用synchronized进行同步，但仍是继承自AbstarctList，直接经过Iterator便可访问容器元素，根本不须要获取锁。

哪有解决方法吗？

有，直接在使用iterator处加锁便可，代码示例以下：

能够，那除了对iterator加锁的方式外，还有其余方法吗？

有，上并发容器，它采用的是fail-safe(安全失败)机制：迭代时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历，遍历期间原集合发生的修改迭代器是不知道的，以此避免了ConcurrentModificationException，但一样的迭代器不能访问到修改后的内容。Java中的并发容器放在java.util.concurrent包中，好比可使用CopyOnWriteArrayList来代替ArrayList和Vector。

---

0x五、Kotlin中toList()的原理

---

差点漏了，那位盘友问的为啥加个toList()就能够了，代码示例以下：

跟下源码：

传入的集合类型，大小为5，走else，进toMutableList

啧啧，看到这里，你get到原理没？

• 直接建立了一个新的ArrayList，把原列表做为参数传入初始化；
• 拿新列表的迭代器遍历，移除的是旧列表中的元素，确定互不影响啊，和fail-safe(安全失败)的玩法一模一样。

---

---

参考文献：

• fail-fast到底是个什么鬼？