协程简介
协程是轻量级的线程,它们在某些coroutiue上下文中与launch构建器一起启动。GlobalScope的生命周期与整个应用程序的生命周期一致。
阻塞与非阻塞
先说结论:
- launch不会阻塞线程
- async可以阻塞协程也可以不阻塞协程(无法直接运行在线程里,只能运行在协程里)
- runBlocking会阻塞线程
- suspend会阻塞协程(只能运行在协程里,无法运行在线程里)
- withContext会阻塞协程(只能运行在协程里,无法运行在线程里)
launch不会阻塞所在线程
- 代码
fun main() = runBlocking {
log("准备启动协程")// ::A
GlobalScope.launch {
log("运行协程")// ::B
delay(1)
}
log("代码运行到协程体之外")// ::C
delay(2)
}
- 日志输出
日志: 准备启动协程
日志: 代码运行到协程体之外
日志: 运行协程
- 结论
本例代码中C处的日志比B处先执行,所以证明lunch不会阻塞
async可阻塞也可以不阻塞
不使用await
- 代码
fun main() = runBlocking {
log("A--进入async方法体内")//A
val async = GlobalScope.async {
log("B--开始执行async方法体")//B
delay(1)
log("C--async方法体执行完成")//C
}
log("D-- async方法体外执行")//D
delay(2)
}
- 日志
日志: A--进入async方法体内
日志: D-- async方法体外执行
日志: B--开始执行async方法体
日志: C--async方法体执行完成
- 结论
async不会阻塞线程 把上一个例子做一些小改动
使用await
- 代码
fun main() = runBlocking {
log("A--进入async方法体内")//A
val async:Deferred<Unit> = GlobalScope.async {
log("B--开始执行async方法体")//B
delay(1)
log("C--async方法体执行完成")//C
}
async.await()//加了这样一个调用
log("D-- async方法体外执行")//D
delay(2)
}
- 日志
日志: A--进入async方法体内
日志: B--开始执行async方法体
日志: C--async方法体执行完成
日志: D-- async方法体外执行
- 结论
async如果加上了await就会阻塞线程,
runningBlock会阻塞所在线程
- 代码
fun main() {
log("A--准备进入runningBlock") //A
runBlocking {
log("B--进入runningBlock" )//B
delay(1)
log("C--执行完成runningBLock")//C
}
log("D--runBlocking代码块外执行")//D
runBlocking {
delay(3)
}
}
- 执行结果
日志: A--准备进入runningBlock
日志: B--进入runningBlock
日志: C--执行完成runningBLock
日志: D--runBlocking代码块外执行
- 结论
本示例中runBlocking代码块中的B和C顺序执行完成后才执行的代码块外面的D,这证明了runningBlock会阻塞线程。
suspend函数会阻塞协程
suspend会阻塞所在的协程,不会阻塞线程,因为suspend无法在线程内部调用
- 代码
fun main() = runBlocking {
log("A--调用suspend函数前")
wait2Second()
log("B--调用suspend函数后")
delay(3)
}
suspend fun wait2Second() {
log("C--调用suspend函数开始")
delay(2)
log("D--调用suspend函数结束")
}
- 日志
日志: A--调用suspend函数前
日志: C--调用suspend函数开始
日志: D--调用suspend函数结束
日志: B--调用suspend函数后
- 结论
suspend函数会阻塞协程
withContext是否会阻塞协程
- 代码
fun main() = runBlocking {
log("A--执行withContext前")
withContext(Dispatchers.Default){
log("B--开始执行withContext")
delay(1)
log("C--withContext执行完成")
}
log("D--执行withContext后")
delay(2)
}
- 日志
日志: A--执行withContext前
日志: B--开始执行withContext
日志: C--withContext执行完成
日志: D--执行withContext后
- 结论
withContext会阻塞协程,withContext只能运行在协程,不能运行在线程中。本例中的Default改为Main就会报错,因为Main相当于运行在主线程
等待一个作业
launch方法会返回一个Job对象,Job对象调用了join方法后,会等待launch协程体执行完成再继续后面的任务。
join方法只能在协程体里面调用,不能在线程中调用
- 代码
fun main() = runBlocking {
log("A")
val job = GlobalScope.launch {
log("B")
delay(2)
log("C")
}
log("D")
job.join()
log(E)
}
- 日志
日志: A
日志: D
日志: B
日志: C
日志: E
- 结论
join会等待协程体执行完成
结构化并发
使用GlobalScope.launch是很危险的,因为它创建的是一个顶层协程,如果launch方法里执行了耗时任务,而我们的对象过早的被回收就会发生内存泄露。
这种情况的解决办法就是在我们指定的作用域范围内开启协程
举例:
- 代码
fun main() = runBlocking {
log(A)
//这个launch和GlobalScope.launch是不同的,它是运行在runBlocking的作用域内的
launch {
log(B)
delay(2)
log(C)
}
log(D)
}
- 日志
日志: A
日志: D
日志: B
日志: C
- 因为launch方法运行在外部runBlocking作用域内,
作用域构建器(直接抄官方)
除了由不同的构建器提供协程作用域之外,还可以使用 coroutineScope 构建器声明自己的作用域。它会创建一个协程作用域并且在所有已启动子协程执行完毕之前不会结束。
runBlocking 与 coroutineScope 可能看起来很类似,因为它们都会等待其协程体以及所有子协程结束。 主要区别在于,runBlocking 方法会阻塞当前线程来等待, 而 coroutineScope 只是挂起,会释放底层线程用于其他用途。 由于存在这点差异,runBlocking 是常规函数,而 coroutineScope 是挂起函数
- 代码
fun main() = runBlocking { // this: CoroutineScope
launch {
delay(200L)
println("Task from runBlocking")
}
coroutineScope { // 创建一个协程作用域
launch {
delay(500L)
println("Task from nested launch")
}
delay(100L)
println("Task from coroutine scope") // 这一行会在内嵌 launch 之前输出
}
println("Coroutine scope is over") // 这一行在内嵌 launch 执行完毕后才输出
}
- 输出
提前函数重构
我们可以把launch、async中的代码抽离成一个suspend函数,这样的代码更便于阅读
协程很轻量
全局协程像守护进程
GlobalScope启动的协程并不会使进程保活
其它
- delay函数不会阻塞线程,但是会挂起协程,所以delay只能在协程中调用
最后
为了让大家更好的去学习和提升自己,我和几位大佬一起收录整理的 Flutter进阶资料以及Android学习PDF+架构视频+面试文档+源码笔记 ,并且还有 高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料……
这些都是我闲暇时还会反复翻阅的精品资料。可以有效的帮助大家掌握知识、理解原理。当然你也可以拿去查漏补缺,提升自身的竞争力。
如果你有需要的话,可以前往 GitHub 自行查阅。