kotlin

kotlin runBlocking引起的死锁

2018-09-19  本文已影响0人  capcNote

近来我在自己负责的项目中大量应用了协程,提高了很多服务的响应时间。。直到一次需求,测试环境一切都很美好,上线第二天线下反馈一个聚合页经常超时卡死。分析日志发现,其中一个服务实例虽然进程没挂,但日志已经停止打印,卡死在聚合页的逻辑,下游的远程服务一切正常,至此原因很明显了:死锁。

原因分析:

接口业务逻辑内使用了大量的async{...}异步协程,用来执行rpc调用、提高吞吐,很多底层方法用了runBlocking{...}来构造(其实为了少写点suspend挂起函数...方便调用)。另一方面runBlocking{...}可以保证块内逻辑顺序、阻塞执行,直觉是这里出现了问题。
搜到了一篇kotlin社区内的帖子,很多回复点出了问题所在:

默认的CommonPool线程数有限,如果底层方法使用runBlocking{...}执行阻塞逻辑、并且顶层方法大量启动并行任务调用这个方法,此时,这些并行的阻塞任务、底层协程均被调度到CommonPool,协程本质上还是需要在线程下才能执行的,可此时线程资源已经全部被阻塞任务占用,阻塞任务又在等待其内的协程返回结果,自此形成了死锁。

As a general rule, the code that runs inside parallel streams should never block (runBlocking should not be used there).

解决方案:

  1. 协程均调度到一个单独的自定义线程池,并将线程数调高。
  2. 底层方法消除runBlocking{...}的使用、均使用suspend重构为挂起函数。(推荐)

方案1改动量较小,但若访问量继续加大,很容易再次复现问题,并且大量的线程切换会适得其反,因此只适合像我这样已经出了问题的情况下的临时处理方案。
根本的处理则是如方案2,在并行任务中彻底消除runBlocking{...}的使用。

附一个协程死锁的简单实现:

fun main(args: Array<String>) = runBlocking {
    println("--- main start ---")
    //创建任务list,若默认CommonPool线程数很多,可加大任务数量模拟,p.s. List(50)
    val deferredList = List(10) {
        serviceAsync(it)
    }
    //并行启动任务,模拟大量请求下的并发情况
    deferredList.parallelStream().forEach {
        runBlocking {
            println("start")
            println("${it.await()} end")
        }
    }
    //死锁发生、永远不会执行到这里
    println("--- main end ---")
}

/**
 * 异步并行任务
 */
fun serviceAsync(order: Int) = async(CommonPool, CoroutineStart.LAZY) {
    blokingIoWork()
    order
}

/**
 * 模拟耗时的io操作
 */
fun blokingIoWork() = runBlocking {
    delay(2, TimeUnit.SECONDS)
}
上一篇 下一篇

猜你喜欢

热点阅读