近来我在自己负责的项目中大量应用了协程,提高了很多服务的响应时间。。直到一次需求,测试环境一切都很美好,上线第二天线下反馈一个聚合页经常超时卡死。分析日志发现,其中一个服务实例虽然进程没挂,但日志已经停止打印,卡死在聚合页的逻辑,下游的远程服务一切正常,至此原因很明显了:死锁。
原因分析:
接口业务逻辑内使用了大量的async{...}
异步协程,用来执行rpc调用、提高吞吐,很多底层方法用了runBlocking{...}
来构造(其实为了少写点suspend
挂起函数...方便调用)。另一方面runBlocking{...}
可以保证块内逻辑顺序、阻塞执行,直觉是这里出现了问题。
搜到了一篇kotlin社区内的帖子,很多回复点出了问题所在:
默认的CommonPool
线程数有限,如果底层方法使用runBlocking{...}
执行阻塞逻辑、并且顶层方法大量启动并行任务调用这个方法,此时,这些并行的阻塞任务、底层协程均被调度到CommonPool
,协程本质上还是需要在线程下才能执行的,可此时线程资源已经全部被阻塞任务占用,阻塞任务又在等待其内的协程返回结果,自此形成了死锁。
解决方案:
- 协程均调度到一个单独的自定义线程池,并将线程数调高。
- 底层方法消除
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)
}