跳至主要內容

使用Kotlin协程的崩溃纪实(一)

guodongAndroid大约 6 分钟

使用Kotlin协程的崩溃纪实(一)

前言

由于笔者对Kotlin协程缺乏深刻的理解以及充分的实践,导致在实际工作中使用Kotlin协程时遇到一些崩溃的问题。

那么本文主要记录遇到的这些崩溃问题,这是其中之一。

背景

在Kotlin协程中如果不能合理的使用for-in循环,可能会抛出ConcurrentModificationException异常导致崩溃。

伪代码

下面是符合背景中描述的伪代码:

fun main() {
    val ml = mutableListOf<Int>()

    for (i in 0..10) {
        ml.add(i)
    }
    println(ml)

    val run = RunSuspend<Int>()

    val scope = CoroutineScope(EmptyCoroutineContext)
    scope.launch {
        // 协程A
		try	{
            for (i in ml) {
        		log("${suspendWork(500L)}: $i")
			}
			run.resumeWith(1)
        } catch (e: Exception) {
            e.printStackTrace()
            run.resumeWith(-1)
        }
    }

    val await = RunSuspend<Boolean>()
	await.await(1_000L)
    
    scope.launch {
        // 协程B
        log("Add 11: ${ml.add(11)}")
    }

    val code = run.await()
    log("Finish with [$code]")
}

private suspend fun suspendWork(timeout: Long) = suspendCoroutine<Boolean> { continuation ->
    thread {
        Thread.sleep(timeout)
        continuation.resume(Random.nextBoolean())
    }
}

private val DF = SimpleDateFormat("HH:mm:ss.SSS")
private fun log(any: Any) {
    println("[${DF.format(Date(System.currentTimeMillis()))} ${Thread.currentThread().name}]: $any")
}

上面的伪代码大致的逻辑如下:

  1. 创建一个可变列表ml并添加[0, 10]这11条数据,
  2. 创建一个RunSuspend的实例run,用于主线程等待协程执行完毕,否则主线程退出,协程无法执行完毕,
  3. 创建一个协程作用域scope,启动一个协程A,在协程中执行for-in循环,在循环中调用挂起函数suspendWork模拟执行耗时任务,其每500ms输出一条日志,循环执行完毕后或抛出异常时调用run.resumeWith通知协程执行完毕并停止阻塞主线程,
  4. 再创建一个RunSuspend的实例await,用于阻塞主线程1000ms,然后启动一个新的协程B为可变列表ml新增一条数据,
  5. 调用run.await阻塞主线程并等待协程A执行完毕。

伪代码执行的期望结果如下:

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[22:10:39.588 DefaultDispatcher-worker-1]: true: 0
[22:10:40.085 DefaultDispatcher-worker-1]: Add 11: true
[22:10:40.095 DefaultDispatcher-worker-1]: false: 1
[22:10:40.598 DefaultDispatcher-worker-1]: true: 2
[22:10:41.104 DefaultDispatcher-worker-1]: true: 3
[22:10:41.610 DefaultDispatcher-worker-1]: true: 4
[22:10:42.114 DefaultDispatcher-worker-1]: false: 5
[22:10:42.619 DefaultDispatcher-worker-1]: false: 6
[22:10:43.122 DefaultDispatcher-worker-1]: false: 7
[22:10:43.628 DefaultDispatcher-worker-1]: false: 8
[22:10:44.132 DefaultDispatcher-worker-1]: true: 9
[22:10:44.637 DefaultDispatcher-worker-1]: false: 10
[22:10:44.638 main]: Finish with [1]

笔者期望伪代码可以正常的执行完毕。

但是,实际上伪代码执行的结果如下:

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
[22:11:34.338 DefaultDispatcher-worker-1]: false: 0
[22:11:34.836 DefaultDispatcher-worker-1]: Add 11: true
[22:11:34.839 DefaultDispatcher-worker-1]: true: 1
[22:11:34.840 main]: Finish with [-1]
java.util.ConcurrentModificationException
	at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
	at java.util.ArrayList$Itr.next(ArrayList.java:851)
	at CoroutinesKt.case1(Coroutines.kt:56)
	at CoroutinesKt.access$case1(Coroutines.kt:1)
	at CoroutinesKt$case1$1.invokeSuspend(Coroutines.kt)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)

执行结果分析:

  1. 协程中的for-in循环输出了2条日志,每次输出日志时,其实已经是每次遍历执行500ms之后了,
  2. 阻塞主线程1000ms后,我们在启动的协程B中为可变列表ml新增了一条数据:11,
  3. 在第三次遍历时协程A中抛出了一个异常:java.util.ConcurrentModificationException

分析

为什么执行结果会与我们期望的结果不同呢?接下来我们分析下原因。

首先我们再仔细观察下协程中的代码:

scope.launch {
    try	{
        for (i in ml) {
            log("${suspendWork(500L)}: $i")
        }
        run.resumeWith(1)
    } catch (e: Exception) {
        e.printStackTrace()
        run.resumeWith(-1)
    }
}

按照笔者的想法,for-in循环的执行逻辑如下:

  1. 循环体是在同一个线程中执行,
  2. 循环体是同步且顺序执行的,

可以简单理解循环体的执行是线程安全的。

真的线程安全么?

针对第一点,目前的scope没有指定运行的线程,那么协程默认是在Default线程池中执行,同时循环体的每次执行都会触发两次线程切换,其一是从launch协程体执行的线程切换至suspendWork挂起函数执行的线程,其二是suspendWork挂起函数执行完毕后,从suspendWork挂断函数执行线程切换回launch协程体执行的线程,而launch协程体执行的线程由Default线程池分配,线程池分配线程存在不固定性,所以循环体在同一个线程中执行不能成立,自然不能称为是线程安全的。

为什么会有这样的想法呢?

正如前言中所说,笔者对协程缺乏深刻的理解以及充分的实践,而协程的一大特点是:使用「同步代码」写出异步程序。

其实笔者就是被「同步代码」这一表象所“欺骗”,这也是笔者对协程缺乏深刻理解的佐证。

使用「同步代码」写出异步程序,对程序猿来说这是多么美好的事情,但是如果对协程理解的不够深入,不清楚它背后的逻辑,那么很容易就像笔者一样被它简单的表象所“欺骗”。

针对第二点,协程的特点是使用「同步代码」写出异步程序,在循环体中调用了挂起函数,那么循环逻辑必然是异步程序,所以第二点也不成立。

异常原因

in在集合遍历时是一个操作符重载关键字,我们把鼠标放在in关键字上,然后按住ctrl(windows)command(macos)键,再点击鼠标左键,会看到它其实重载的是Iteratornext()hasNext()方法,所以for-in循环其实是通过Iterator来使用的。

Iteratornext()方法中会检查集合是否被修改,如果被修改则抛出java.util.ConcurrentModificationException异常。

如何修复?

修复方案有多种,比如:

  1. 在协程体中,先对ml集合进行一次浅拷贝赋值给ml2,然后遍历ml2,如此便不会抛出上述异常,但是无法遍历ml中新增的元素,
  2. 使用加锁的方式,遍历ml集合时不允许其他线程对ml集合进行更新,
  3. 其他方式,

具体选择哪种修复方案,这里可以根据业务场景的不同而选择不同的修复方案。

总结

本文记录的笔者在使用Kotlin协程过程中遇到的for-in崩溃问题,通过伪代码笔者复现了崩溃问题,并分析了问题产生的原因以及给出一些修复方案供选择参考。

其中最重要的是发现自身的不足,发现自己的不足也是一种进步。

总之就是:

纸上得来终觉浅,绝知此事要躬行。